String freeze for GNOME 41

[Michael Catanzaro <mcatanzaro gnome org>]

Hi,

I've posted a draft schedule for GNOME 41 development:

https://wiki.gnome.org/FortyOne

The most significant change is that the 41.rc release is moved one week 
earlier, which has implications for i18n. Previously we did this:

90 (or 40.beta) UI freeze, string change announcement period begins
91 (two weeks later) string freeze begins
92 (or 40.rc) (two weeks later) hard code freeze begins
0 (one week later)

For GNOME 40, string freeze began halfway between beta and rc, at the 
same time it always did. This means we had two weeks of string change 
announcement period, then three weeks of string freeze before the final 
release. The string freeze was not associated with any release 
milestone, which was perhaps a little weird, but it was halfway between 
two milestones.

With the 41.rc release moved one week earlier, if we make no changes to 
the timing of string freeze and string change announcement period, we 
would now have this:

40.beta UI freeze, string change announcement period begins
(two weeks later) string freeze begins
40.rc (one week later) hard code freeze begins
0 (two weeks later)

Having string freeze begin one week before 41.rc is not problematic per 
se, but it is strange and makes the schedule more complicated. So I 
have two (contradictory) proposals:

* Start string freeze with 41.rc. Disadvantage: this would reduce 
string freeze from three weeks down to two.
* Start string freeze with 41.beta and remove the string change 
announcement period, increasing string freeze from three weeks to five 
weeks. Disadvantage: it makes changing strings harder for developers, 
and will increase the number of freeze break exception requests.

Either way would simplify the schedule, which is my goal. Any opinions 
on this?

Michael