As mentioned in the matrix channel, I would like to re-iterate on this decision to consider to revise this decision for GNOME Shell.
There are multiple reasons for this, but in particular it’s unclear to me why the decision of coupling mutter package together with GNOME Shell, in fact while indeed they are strictly tied, the fixes that the shell ships during the point releases are always unrelated to mutter changes, and we don’t have a case in which a newer version of mutter is required to run a newer point release shell version.
Basically mutter freezes its API at .0, and since then the shell fixes won’t depend on new mutter features.
So all the past discussions I can find on this topic are:
And they are all related to mutter, it’s not clear to me why GNOME Shell was excluded by the MRE too, since there are no report of regressions.
The only case that is mentioned in the MRU page - unrelated to the shell itself TBH - is not something that applies anymore since no extension, other than the official ubuntu ones (and that are always tested with it) are part of the ubuntu archive.
The current state has lead to a situation in which in Noble we currently have a frankenstein-gnome-shell 46.0 with a ton of patches on top, while upstream did 10 interim releases meanwhile, fixing bugs that our users won’t ever get.
Doing this to me is even more dangerous than just trusting upstream (that, as desktop team we do trust), because we’re adding another point of fragility if we leave in the desktop team hands (only) the decision on what to cherry-pick and what not, despite on trusting a community that is wider than we are and other distros users that may be able to test the very same thing.
This is mostly due to the fact that now we can only be reactive to bugs, and not pro-actively fix things that our users (not really active on launchpad anymore) won’t ever report (but trust me, there are many!).
So in short, given the noble situation we can say:
- We’re far behind in having all the fixes that landed upstream meanwhile
- It implies that many fixes that have been released months after that were actually fixed upstream, with no reason, just the lack of a report
- If any, we end up to receive bugs report very late (and maybe because of a customer) and it’s only then that we’ve an actionable item
- No, do not ask again me to open 20+ bugs for real issues that we have nobody complaining about
- The version we’re currently shipping is hard to be compared to upstream, because full of fixes in different order that at times have been only partially cherry-picked (to keep the change minimal). This creates various potential issues, including:
- Potentially incomplete fixes
- Fixes that to work fully also relying on previous changes that we are not including, thus potentially introducing regressions
- Not having a way to compare with what other distros are shipping, and thus if a problem rises it’s always impossible to tell if it’s ubuntu-specific or if it applies to all.
- Debugging issues we’re supposed to is often hard since they may not happen anymore upstream, and so we may end up spending hours or days before figuring out that the problem was fixed
- Way more work for the desktop team
- We did not record any single 46.x version upstream that had regressions
Given that gnome shell is our most visible face that we put in front of our desktop users, to me it’s quite sad that is so hard for us to provide them the best quality possible, unless every single bug is actually claimed and verified.
So, maybe we’re protecting them from regressions, but also from an improved experience.
So, I’d be happy if we could discuss this anymore, in time for 26.04, given that the current situation only a caused a lower-quality experience for anybody, and way more work for the team in 24.04.
And I’d like that we could define a process, even different from MRU, but easier for us to be able to provide, safely, the latest updated shell to our users.