More proposed release schedule changes

[Michael Catanzaro <mcatanzaro gnome org>]

Hi,

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).

Michael