More proposed release schedule changes


We're going to release GNOME 3.35.91 next week. (Tarball deadline is Saturday! Please release your tarballs now!) Only problem is, nobody is really testing 3.35.90 yet, defeating the purpose of having the beta release.

A couple years ago, we've pushed our releases earlier just a bit (generally about two weeks earlier than we used to do) in order to make it easier for Ubuntu to ship our new stable release. (And Fedora, but Ubuntu ships slightly earlier, so it was the bigger driver behind that change.) My thinking had been that allowing distros more time between our .0 and the distro release date would allow for increased quality, since historically our .0 releases have not been as robust as we would like. (Note: I mostly focus on Ubuntu and Fedora because these distros align their release cycles to ours; nobody else is doing that afaik, so our schedule doesn't have a major impact on other distros in the way it does on Ubuntu and Fedora.)

Well, I'm starting to think this was a mistake. Quality issues with our new stable releases are longstanding problems, but for 3.34 we had a particularly rough time. I don't have a record of how many serious quality issue we had, but it was a lot; it took until 3.34.2 to resolve the most serious of the issues. Now of course we have more problems here than just the release schedule, but the release schedule is a contributing factor. Thing is, most testing of the new GNOME doesn't begin until Fedora branches from rawhide. Well, that happened earlier this week, so most testing is only just now beginning for the earliest of early adopters. Serious testing really heats up around the Fedora beta release. But 3.36.0 is going to be released a week *before* F32 beta, so we're releasing before testing enters its most important phase!

Now, we don't have too much leeway to change the schedule without violating the bounds of our March/September release cadence, which has served us fairly well for a long time. So basically I'm just proposing that we switch back to releasing during late March/September instead of early March/September. If we were to follow roughly the same schedule for 3.38 that we did for 3.34, we'd probably release 3.38.0 on September 9. But I propose September 23 instead (which is in line with what we historically did for most of the past decade). That would move us two weeks later than we are now, which I think should allow us a bit more time to improve the quality of our release based on testing in these distros.

Now, Ubuntu's schedule isn't posted yet, but I guess October 15 seems like the likely final release date for 20.10 (third Thursday of October), and my guess is beta freeze will be September 28 (last Monday of September). That seems a bit tight, but our final tarball deadline for 3.38.0 would be September 19, so it would leave one full week to get 3.38.0 in before the 28th. Since we normally have three weeks between our .0 and our .1, that means Ubuntu wouldn't be able to ship our .1 regardless. The main difference should be an extra two weeks of bugfixing for the .0 release that does ship, so I'm thinking that should only improve quality. Ubuntu folks, please confirm if this should work OK for you.

Under this scenario, Fedora 33 beta would likely release with 3.37.91 and a zero-day update to 3.37.92 available. I could wish for it to release with 3.37.90 instead, but I don't think it's possible for us to move 3.38.0 any later without causing problems for Ubuntu. Fedora 33 will release with 3.38.1 regardless of this change (assuming we allow it in past Fedora final freeze, which we usually do).


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]