Hey @raof, thanks for the tracker review. You have a point but those changes are a bit of special cases so unsure we should remove tracker from the MRE list over it
@export, that’s a new option to the command line utility. While technically it’s a feature it’s also something not impact users or part of the desktop integration so basically it can’t impact existing users. The command is used to be able to export the data to the new tracker3 service format, which newer GNOME and some flatpak apps started to use. It does sound like something worth adding in a stable update to have users able to migrate their data if needed
@renaming, the use of ‘blacklist’ has been political recently, the rename to ‘blocklist’ is a trivial replace in one source, one can argue that was not needed in the stable serie though…
Well, GNOME is generally quite open to add mini-features and cleanups to micro releases, given they may improve user usage for a tool. So if you look at microrelease changes for many components you would find some big changes at least.
Although, we trust that GNOME used them in the unstable branch for some long time, and the community tested them in the unstable releases (or in the new stable ones when they are out).
I think the point of the MRE in the first place is: We trust what GNOME community considers stable.
If the point here is not to delegate such role anymore, and don’t trust what GNOME upstream thinks is stable, we can just drop the MRE at all.
I would like to add something regarding the shell extensions that are synced from Debian. The gnome-shell stack is always ahead in Ubuntu than Debian. For example, by the time Ubuntu 20.04 was released with gnome-shell 3.36, shell extensions developers and Debian maintainers didn’t have the chance to package the extensions that support 3.36, and Debian unstable / testing was still mostly on gnome-shell 3.34 including the shell extensions. So the extensions that get synced from Debian before the freeze usually support the older shell version and not up-to-date.
The dash-to-panel extension, for example, got Ubuntu 20.04 and gnome-shell 3.36 compatibility fixes in version 36, which was released on 25 April. https://github.com/home-sweet-gnome/dash-to-panel/tree/v36
I personally had to ask the Debian maintainer of gpaste to quickly update the application, including its shell extension, to version 3.36.3 in order to support gnome-shell 3.36 before the Ubuntu 20.04 release, and filed a sync request after the Debian sync freeze:
Has a consensus been reached regarding what should be in the list of “core GNOME modules and apps”? I ask as there are multiple uploads to the focal Stable Release Updates queue which reference the GNOME MicroReleaseException but have not appeared in this discussion. It would be good to have a final list from which we can all work.
One recent example of issue is https://bugs.launchpad.net/bugs/1925771 which is about one of the games, those are following the GNOME schedules and freezes and we never had problems with one of their updates, could they be added to the exception?
There’s been some realtime discussion of this in #ubuntu-release just now.
To help drive this forward, I’d like to take one step back if I may. A question for the desktop team: how would you like this exception defined, going forwards? Is it going to be a simple list of source packages? A reference to a list elsewhere? Some criteria to apply to decide if a given source package is included or excluded? Some combination? There will presumably need to be some exceptions, of course, and that’s fine. But if we’re going to keep being asked to consider and add exceptions on an individual basis, then we all need to understand that’s going to take some time, and we’ll want to come up with some criteria for considering them. It’d be nice to come up with some language to describe what we want the list to be, which are exceptions and which are generated, and then try and keep the description small.
@raofgave us a great start by giving us a candidate generated list, and some manual exceptions. @3v1n0asked for further exceptional additions (I think) and then @seb128asked for gnome-chess. It’d be nice to reduce this to a single reference list again. Before I do that, Is there anything else I missed?
In an effort to drive this forward, my next post will be a wiki post (if I’ve understood how to use Discourse). My intention is that it will be a draft that we can work on together, and once approved it can be copied to the Ubuntu wiki and this thread will then be concluded.
I encourage the desktop team and the SRU team to edit the wiki as they wish, aiming towards consensus and approval. Discussion can follow in further posts as we work towards that.
My criteria for approval would be:
The desktop team are happy.
The SRU team are happy.
The document makes it unambiguous and straightforward to understand whether a given Ubuntu source package in a stable release is covered or not.
Any requirements for uploads are clear, so that a) it’s easy for the desktop team to be confident in advance that requirements are met such that the SRU team will accept their uploads; and b) it’s easy for the SRU team to review an upload against those requirements.
Any requirements for SRU verification are clear, so that a) it’s easy for the desktop team to be confident in advance that the verification they perform will be accepted by the SRU team; and b) it’s easy for the SRU team to review verification performed against those requirements.
I’ve sorted the list of packages so it’ll be easier to read, I don’t believe I dropped anything during that process but somebody might want to double check.
Why was libsecret removed in your manually curated list?
It’s been a while, but I think my reasoning was that this is closer to core FDO infrastructure - my understanding was that both GNOME and KDE implemented or were planning to implement the FDO Secret Service API, and so this would be usable by both.
Having a bit more of a look around, KDE looks to have largely abandoned that, so maybe libsecret should be on the MRE list.
Additionally why was gupnp removed from your list when rygel (which is on the list) depends on a binary provided by it?
I don’t think I could tell you now . Maybe it looked more used-outside-of-GNOME? I’ve no particular objection to it being on the MRE list.
accessibility related packages which are maintained following the upstream schedule and part of GNOME: accerciser, at-spi-atk, at-spi-core, atk
standard GNOME softwares maintained in cadence with GNOME and which from history can be trusted: evolution (+ews, also those usually go in locked updated with evolution-data-server which was already on the list), seahorse, gnome-games
we never had issues with the games, the impact is low and they follow the upstream cadence and freezes. They are small components but our users appreciate to get those bugfixes, they are not important enough though that we could justify spending days doing the paperwork of creating a bug and testcase for every commit so if we don’t have the exception it basically means we will not be able to provide those updates anymore.
GNOME doesn’t have formal testplans written down that they follow for those updates if that’s what you mean? They basically rely on community testing the same way as we do when we release a new Ubuntu version
I note that gnome-maps is in the proposal for an exception. Thanks for that @rbasak and team
gnome-maps is a good example of the exception benefit for focal users.
Upstream state that the fix for this failure (where the application no longer launches) is covered by their current 3.36.7 microrelease - focal’s version is currently 3.36.1
Its fortunate in this case that the fix for the failure is a relatively small patch which is the process of being evaluated and hopefully rolled out as part of the standard SRU process.
So, it’s been a year. What is stopping us from completing this MRE documentation?
We don’t have an algorithm for updating this list other than “Desktop team member asks the SRU team to consider adding something to the list”, but that shouldn’t be a blocker.
I don’t believe we’ve settled the “How do we handle gnome-shell uploads with respect to packaged extensions” question.
There doesn’t seem to have been a clamour for a Vala MRE process, so we can probably just drop that.
What should the test-plan be for SRU verification.
I think the next thing to do here is to drop everything which is not yet decided from the list, and point the GNOME MRE documentation on the Wiki to the list. As I understand it, that means that gnome-shell and the GNOME games get removed for now.
This makes the cases which are clearcut clear, so is an improvement on the status quo.
For 4. - In the past the test plan has been poke around and check that things haven’t caught fire , and while I think we can do something better, for now I’d be happy with that.
This is explicitly not expected to be the final state - gnome-shell obviously belongs on the list, once we’ve decided how to handle the reverse-dependencies, and I’m inclined to include the GNOME games. This is intended to be the easiest thing to do now that makes the situation better while we work out what to do with the difficult cases.
Thanks Chris for posting an update on that topic. Speaking from a desktop perspective, moving forward with the simplified-list-without-the-items-in-discussion seems fine, better than the current blocked situation.
Not having vala included in the GNOME MRE was previous agreed on yes. There is always the option to go through the MRE process specifically for it if we believe that it should also have an exception.
Was there anything else needed to make gnome-shell an acceptable candidate?
On the testplan, it would be nicer to have a description for each component but that requires work. What about starting with a ‘ensure it is still working by poking at it as you can’ and then we will try to update the wiki for each SRU we do from now one which isn’t covered yet?
I have some notes from a discussion I had out-of-band with Seb on 30 June 2021. At that time I tried to distill a set of remaining steps that could conclude this matter. I’ll paste them here for reference - some of these are already addressed.
Refine how the list is built
Rather than having a static list describing the components it would be better to have a definition pointing to an upstream set (gnome core + sdk + …?) and on top a manual list of exceptions we want to see added.
This way if GNOME is adding new components they should be covered by the exception without having to discuss with the SRU team again.
Decide what we do with the gnome-shell rdepends
We want to avoid breaking components provided in the Ubuntu archive when doing a SRU
Special case for the games
Those are only games, they are not something users rely on so the regression potential is limited. Desktop would like to see them included in the exception even if they are not core component and don’t have testsuites, so they can get updated at lower cost.
It is agreed that if a regression is found it is fine to revert or delete the SRU.
Would that be acceptable to the SRU team?
Describing the SRU verification steps
The wiki page describing the exception should include the verifications to be done with the updates. We probably want domain specific steps for some components at least
SRU team ack
The SRU team needs to sign off the list once they agree with what is there
Vala
Vala is a special case, we will keep out of the current MRE discussion and create a separate topic for it later if needed
. Maybe it looked more used-outside-of-GNOME? I’ve no particular objection to it being on the MRE list.
poke around and check that things haven’t caught fire