Ubuntu
mixxx package

Comment 8 for bug 1804513

Revision history for this message

Robie Basak (racb) wrote on 2019-03-29: Re: Cosmic: Mixxx 2.1.3 is not stable with Qt5

#8

We can certainly consider this _if_ the current version in Cosmic really is a problem for users that cannot practically be fixed any other way. But please could you actually demonstrate that? For the only bug actually linked, surely a cherry-pick would be lower regression risk for existing users?

> We as Mixxx team do not support 2.1.x qt5 builds. So the user is pretty alone with issues with throws a bad light on Mixxx.

We certainly appreciate involvement from upstreams, but I don't think this qualifies as an SRU justification in itself. "We...do not support" is certainly not a reason. You're entitled to choose not to support what you wish (or more specifically you get to choose what you want to spend your time on), but such a position is certainly not a justification to ignore the stability* promises we make to Ubuntu users.

The focus on stable release updates must be on users, and their expectation is of stability* in that, in general, no major version updates are expected to pull the rug out from under their feet. What can we do to fix these problems for this set of users? How difficult would it be to cherry-pick bug fixes for them? If cherry-picking is practical and would avoid problems for users successfully using the Cosmic package today, why aren't we doing that?

Note that there are only four months left of support for Cosmic, and that Disco will be out soon. It seems to be that the benefit of a major update now would be limited, compared to the consequences of ignoring our stability* promise to users. A user who tries to start using the Cosmic package in three weeks will have the option of using Disco. A user who is successfully using the Cosmic package today might never use Ubuntu again if we break our stability promise and this destroys their performance.

These are the promises we make to users for packages that ship as part of the distribution. I can understand that you may find this frustrating, but please remember that users of stable* distributions _want_ this policy. If you would prefer to have control of your own release management directly to your users, you might consider shipping a snap (http://snapcraft.io/).

* Stability means different things to different people. In this context I don't mean "no bugs"; obviously there are bugs and achieving no bugs is generally not practical. In this context I mean "doesn't suddenly change behaviour".

To be clear, I'm not ruling out an update to 2.2.x in Cosmic, but I think there needs to be a real justification that includes an explanation of the actual bugs actually impacting users in Cosmic and why the fixes cannot practically be cherry-picked.

We can certainly consider this _if_ the current version in Cosmic really is a problem for users that cannot practically be fixed any other way. But please could you actually demonstrate that? For the only bug actually linked, surely a cherry-pick would be lower regression risk for existing users?

> We as Mixxx team do not support 2.1.x qt5 builds. So the user is pretty alone with issues with throws a bad light on Mixxx.

We certainly appreciate involvement from upstreams, but I don't think this qualifies as an SRU justification in itself. "We...do not support" is certainly not a reason. You're entitled to choose not to support what you wish (or more specifically you get to choose what you want to spend your time on), but such a position is certainly not a justification to ignore the stability* promises we make to Ubuntu users.

The focus on stable release updates must be on users, and their expectation is of stability* in that, in general, no major version updates are expected to pull the rug out from under their feet. What can we do to fix these problems for this set of users? How difficult would it be to cherry-pick bug fixes for them? If cherry-picking is practical and would avoid problems for users successfully using the Cosmic package today, why aren't we doing that?

Note that there are only four months left of support for Cosmic, and that Disco will be out soon. It seems to be that the benefit of a major update now would be limited, compared to the consequences of ignoring our stability* promise to users. A user who tries to start using the Cosmic package in three weeks will have the option of using Disco. A user who is successfully using the Cosmic package today might never use Ubuntu again if we break our stability promise and this destroys their performance.

These are the promises we make to users for packages that ship as part of the distribution. I can understand that you may find this frustrating, but please remember that users of stable* distributions _want_ this policy. If you would prefer to have control of your own release management directly to your users, you might consider shipping a snap (http://snapcraft.io/).

* Stability means different things to different people. In this context I don't mean "no bugs"; obviously there are bugs and achieving no bugs is generally not practical. In this context I mean "doesn't suddenly change behaviour".

To be clear, I'm not ruling out an update to 2.2.x in Cosmic, but I think there needs to be a real justification that includes an explanation of the actual bugs actually impacting users in Cosmic and why the fixes cannot practically be cherry-picked.