"GNOME (only the core modules and apps, not the entirety of what is hosted on gnome.org) a(approved on 2012-06-22)"
Unfortunately, as far as the SRU team is aware, there isn’t anywhere which lists what are the core GNOME modules and apps. There have been a number of SRUs straddling the line - is Vala a core GNOME component? Is librsvg? - and it would be helpful to have a definitive list of the components covered by the MRE.
Ideally this list will end up on the Wiki page, but this seems like a sensible place to decide what should be on that list before putting it there.
From the GNOME pov it’s considered a GNOME component whatever is under the GNOME namespace in gitlab, so: https://gitlab.gnome.org/GNOME/.
However, there are indeed some other dependencies that are core dependencies that might be under the FDO umbrella (or others). So for those (a list can be defined as per gnome-build meta dependencies) I guess we should have some clear statement.
The things under the GNOME namespace might be GNOME components, but I’m pretty sure not all those 400+ projects are core GNOME components - the perl GTK2 bindings, for example, don’t seem likely to be core GNOME anymore
Pulling out the things under the gnome-build meta, it looks like a sensible list would be
Possibly some more out of sdk/ would be sensible, but that also includes a bunch of stuff that should clearly not be covered, like Kerberos and WebKit .
In the case of Vala, I have one further question. As far as I understand, a Vala update will provide no immediate benefit in an SRU except in the case that reverse build dependencies are rebuilt. The current SRU microrelease update request does not request that. So is that worth doing at all? Whether or not Vala is a core GNOME component, is an exception to the exception warranted here? For example: what if we said that we only update Vala if there’s specific SRU-qualifying-under-normal-rules user impact in a package that will be fixed by the Vala update and will also be rebuilt as part of the update?
Otherwise my concern is that we risk introducing regressions by updating Vala that will only expose them on further SRUs of other components, that will be much harder to pin down as a result. On the other hand, not updating Vala would not risk this class of regression, and there wouldn’t be any impact to users of Vala-built packages.
There is one use case not covered here: a user might be directly using Vala as published in Ubuntu to build something not in the archive. I propose to accept SRU requests for that use case on an individually assessed case by case basis.
Another relevant datapoint is bug 1892245. As far as I understand, this is a shell extension that was regressed by a microrelease update to gnome-shell due to a deliberate API change in gnome-shell.
@raof is planning to generate a list of packages that are in-scope based on the above discussion.
There are a couple of exceptional cases in relation to GNOME microrelease updates:
We don’t consider that Vala will be included as part of the GNOME MRE. Regardless, the Vala situation is special as it’s generally necessary to also rebuild reverse build dependencies for a Vala SRU to have any effect. If Vala microrelease updates are desired, this will need to be justified and requested independently (whether as a one-off or a standing documented case).
Microrelease updates to gnome-shell are at risk of regressing packages providing gnome-shell extensions as we discovered in the case of LP: #1892245. Going forward, we’d like to see suitable mitigations for this type of regression before we publish gnome-shell microrelease updates, such as through thorough testing of reverse dependencies.
That said, there are some that are clearly GNOME projects and on which mostly GNOME core apps depend on (there could be few external cases) and where upstream can be trusted that a new point release works with the whole ecosystem.
Such as:
at-spi2-atk
gspell
gssdp
libcanberra
libdazzle
libgdata
libgee
libgit2-glib
libgtop
libgusb
libpeas
libsoup # Maybe this could be kept away
pyatspi
sysprof
template-glib
vte # There may be gnome-terminal SRUs that require bumping this as well
zenity
That being said, I think we should also define a procedure (that should be quite straight forward) to update the list whenever new upstream GNOME projects have been added (or moved away from the GNOME umbrella).
Moving this conversation here as this thread is about SRU policy vs. the other one that is only about a specific update.
Assuming that you mean adding a Breaks: package relationship in a gnome-shell microrelease SRU, such that extensions installed from the archive will need to be removed before gnome-shell can be upgraded, I’m not sure that’s safe. If there’s a subsequent security update to gnome-shell, what’s that going to mean for users who are using such shell extensions from the archive? Will apt refuse to install the security update, or will apt force the removal of the extension packages? Either way seems unacceptable to me.
I think an essential requirement for an SRU is that nothing in the archive is knowingly broken as a result of it. We released with these extension packages, and our stability promise we make is that we won’t break them. It then follows that declaring “extensions we can’t support” cannot be used as an excuse to break this promise. However this is probably outside of the scope of the SRU team to decide; I think that if we want to deliberately break compatibility with other packages in the archive in an SRU, then that’s outside the scope of the microrelease update permission given to the SRU team by the Technical Board and so such an exception proposal would have to go back to the Technical Board for their consideration.
An alternative might be not to release such extension packages at all if they’re going to block gnome-shell microrelease updates like this because nobody is committing to do the necessary work. I am generally in favour of removing packages that aren’t being looked after and are also blocking progress. Again that’s not up to the SRU team though; that’d be something to clear with the release team.
Note however that in the case of this particular regression we found that people are using the package and @fcole90 did step up to do the necessary work. Whatever we do, I think we need to figure out how to fit those extension packages into the gnome-shell SRU process so that those who are willing to look after these packages like this can continue to do so without users being regressed first.
I concur, with the caveat that there are sometimes cases where breaking a package in the archive is the least-worst choice.
Certainly each instance would need to be judged individually. The GNOME MRE should not be a blanket permission to break packaged¹ extensions; all packaged extensions should be tested against a new GNOME Shell, and any regressions should be flagged and investigated to see if they can be resolved.
¹: As our policy is that people using 3rd party repositories are on their own, and extensions.gnome.org is a 3rd party repository, it is acceptable (although not ideal) to break unpackaged extensions in a gnome-shell SRU.
Sure, my point wasn’t to break it in a SRU, but to ensure that those mostly unmaintained extensions (I personally maintain the dashtodock one, even upstream, but I normally just package it in the ubuntudock variant) don’t figure out as supported by us before the release.
While debian may have other preferences on that, IMHO it’s not possible to ensure that all the extensions in archive (41 right now!!) are not broken by some detail of an upstream update.
And this is mostly for the nature of the Shell, that being in JavaScript gives us very few tools to ensure if an “API” has changed or not (considering also that most of those extensions use internal properties that shell upstream developers change all the times).
So this would imply run them all, and you’d need to go one-by-one and check the shell logs (as running them all together could lead to other breakages of course).
In that case, I think this means that we cannot (continue to) push microrelease updates of gnome-shell to stable releases because such updates are known to break packaged extensions. The microrelease exception was originally granted by the technical board on the basis that such updates are not expected to break things, and that situation has clearly changed in the case of gnome-shell.
Fixes to gnome-shell will have to be individually cherry-picked and tracked using the usual SRU method. That allows for consideration of accidentally regressing extensions on an individual and more narrowly scoped basis. A grep through the extensions for object API attributes that are being modified in behaviour or being removed should also then be more practical.
I understand this is undesirable, but I don’t see that we have any other choice. It’s a consequence of shipping those extension packages in the first place. Personally I’m in favour of ceasing to ship unmaintained extension packages in future releases. That would resolve this problem and allow gnome-shell microrelease updates to resume in future releases I think, by making testing of extensions during gnome-shell SRU verification practical? If you agree with this approach, I suggest you take it up with the release team.
In that case, I think this means that we cannot (continue to) push microrelease updates of gnome-shell to stable releases because such updates are known to break packaged extensions. The microrelease exception was originally granted by the technical board on the basis that such updates are not expected to break things, and that situation has clearly changed in the case of gnome-shell.
Well, we had so far one recorded case, for an extension that we don’t officially support and that can be fixed also at some later times, indeed this was an unfortunate thing but still it was a minimal impact compared to the tenths of fixes that the silent majority of our users got by getting new point releases earlier.
So, really I don’t see the rational why a such minor problem can just be the reason for making harder and slower for most of users to get a better quality software.
A grep through the extensions for object API attributes that are being modified in behaviour or being removed should also then be more practical.
This is not possible, as said… They may act on the same elements in too many ways that a grep that would work fine in C isn’t applicable to JS monkey-patching.
Fixes to gnome-shell will have to be individually cherry-picked and tracked using the usual SRU method. That allows for consideration of accidentally regressing extensions on an individual and more narrowly scoped basis.
I’m not really sure how this would change the things, if there are regressions and the shell gets verified for the N fixed bugs, it doesn’t mean that it regresses on something else that has not been taken in consideration (nor that could be taken in consideration) when writing the regresssion potential line.
I think you’re conflating “we” here. By “we” I think you mean Canonical, but wearing my SRU team hat I’m speaking for the Ubuntu archive, which is a community project. In that sense, the extension is being supported by volunteers, and we must not undermine the Ubuntu community by ignoring them.
I don’t think regressions that we’ve overlooked are relevant here. The key difference is that we will have carefully considered and done our best to avoid regressing users if we follow the usual process, whereas if we continue to follow your current process then we will be deliberately refusing to even look to check that we haven’t regressed something.
The LTS update is including important fixes and blocking on the basis that it could regress some almost not used universe extensions is quite unfortunate. Realistically users are going to have extensions enabled by other ways and found their system broken in a similar fashion by the update (upstream and SRU), it’s not really something in our hands.
If the SRU team insists that this update is going to need stricter standards that the previous ones we did in focal up to now then the only remaining option is to try to organize testing of the universe available extensions, that is costly in resources and we would prefer to spend effort on more useful problems though…
The SRU team is not blocking this. You can continue to land SRUs for gnome-shell providing that you continue to test such SRUs adequately. What “adequate” means is still up for discussion. However, we now know that gnome-shell upstream microreleases make no effort to maintain API that our extension packages depend on. A regression caused by this API instability has happened in practice. So I am rejecting the idea that you can completely ignore the extension packages. However we haven’t discussed details of exactly how to ensure that extension packages haven’t regressed, and I’m open to discussing pragmatic/realistic approaches to achieve this.
Do you have any data to support your claim of “almost not used universe extensions”? I got the impression that the dash-to-panel extension is quite popular. In any case, we released with these packages. SRU policy has always been that we take appropriate steps not to regress what we released.
There is no change to the standard here. I’m open to making pragmatic exceptions, but I think it’s disingenuous to imply that the standard has changed. gnome-shell microreleases fell short of the standard required. Based on the information we had, we had thought that the gnome-shell upstream microrelease process met the required standard, but it turned out that it does not. We now need to figure out how best to meet the required standard again. That is all.
We don’t have metrics but it’s an universe package users need to opt in for and the number of reports was low when it stopped working, anyway whether it’s 3% or 0.01% of users isn’t going to make a difference is it? Going forward we should just remove those to avoid the issue and then we need to focus out what testing needs to happen on the current LTS
I think we might also want to remove Tracker from the GNOME MRE list?
My understanding is that the MRE is granted on the basis that we have a shared understanding with GNOME what a bugfix release is, and the changelog for the 2.3.4 → 2.3.6 SRU appears to include two things that aren’t obviously bugfixes - an entirely new tracker export command, and renaming some functions for no functional change.
