Right now, gjs has 1.76.2 in lunar-proposed, and I’m accepting 1.72.4 into jammy-proposed.
Which one is newer? Could, for example, 1.72.4 contain fixes for bugs that are only fixed in a 1.76.3 that is not yet prepared for Lunar? If so, then we might be introducing fixes into Jammy that users will then face a regression for if they upgrade to Lunar, which is something we usually try to avoid by asking that later stable releases be fixed first (or at the same time).
This may or may not be the case specifically right now, but generally, is this kind of situation something we should plan against in how we process these SRUs?
Again, I’d be a fan of a test plan with more structure than “make sure GNOME Shell still works correctly” - for example, is it worth checking the journal to identify any new warnings generated to check that they’re harmless?
Would it additionally be worth checking that the supported Shell extensions still work? They obviously have the potential to be affected by any change in the JS environment, but it’s not clear to me how likely they are to hit things that the default Shell doesn’t, so I don’t know if testing them is worthwhile.
FWIW I’ve also marked the GNOME Shell test plan as approved. I still think the Mutter test plan should call out some explicit hardware testing, and there are still some open questions there.
It’s been raised that glib2.0 is a particularly core package, used extensively outside the GNOME ecosystem. As such, does it need either a very stringent test plan, or to be excluded from the GNOME MRE entirely?
That said, I know that historically it has been under the GNOME MRE, and checking the list of regresson-updates-tagged bugs only finds a case of a CVE fix, which was known ahead of time to regress some usecases. This looks like a history of trouble-free microrelease updates, so maybe this is fine?
glib has an extensive test suite used in both build tests and as installed tests run as autopkgtests. glib also triggers a lot of autopkgtests in other packages. glib also has a track record of limiting itself to bugfixes for stable point releases. I believe glib satisfies the usual criteria for “new upstream microreleases”. Unfortunately, much of the rest of GNOME doesn’t have as thorough of automated testing so we need a microrelease exception for GNOME.
Hm. I see I wasn’t very clear in my last message - I was pretty happy with glib2.0, but I wanted to check with the rest of the SRU team.
That’s now been done, and the decision is “glib2.0 is used too widely outside of GNOME to fall under the GNOME MRE policy, but glib2.0 is well-tested and has a long history of trouble-free bugfix updates and so is a standard MRE candidate”.
The next action on this is:
I’ll review (and, presumably, accept) the current glib2.0 upload
I’ll write up a stand-alone glib2.0 MRE test plan page
