Re: GConf reverse string freeze breakage approval

[Christian Rose <menthos gnome org>]

sön 2005-08-14 klockan 09:47 -0600 skrev Elijah Newren:
> On 8/14/05, Mark McLoughlin <markmc redhat com> wrote:
> > On Sun, 2005-08-14 at 15:57 +0200, Danilo Šegan wrote:
> > > Today at 13:48, Mark McLoughlin wrote:
> > 
> > > >     All I'm really saying is that I don't think the hard string freeze was
> > > > in effect when this change was approved or committed.
> > >
> > > And all I'm saying is that I disagree.  But it doesn't matter much
> > > now, we shouldn't make a big fuss out of it since it's already
> > > approved (precisely for the reason that we're *early* in the string
> > > freeze).  There is some merit in the claim that freeze only starts
> > > after the tarball is released, but it's unpractical to make it that
> > > (for explained reasons: tracking 69 modules is simply too much). And
> > > according to schedule, tarballs should have been ready by 8th, so we
> > > are already using that as a guideline.
> > 
> >         Okay, probably the best way to make it less confusing for translators
> > is to say that the freeze kicks in after the release - i.e. in this case
> > it would have been the 11th. Sound reasonable?
> 
> I had thought of freezes and releases the same way Mark does (occurs
> when release is made, at latest the Wednesday specified in the
> schedule; translators would just pick "after Wednesday" if they wanted
> something simple and consistent).  I do see how it wasn't very clear,
> though (the schedule itself is confusing as it spreads the freeze
> begins message over 3 days; well, except for hard code freeze that
> occurs on a Monday because there's no associated release).  Probably
> yet another thing that we need to document better.  That and what
> "after Wednesday" means (start of Thursday for Australia?  for
> Hawaii?)  I should start throwing all this stuff that needs to be
> documented into a list somewhere...

FWIW, I never ever understood freezes this way. The way I interpreted it
(and which to the best of my knowledge was never corrected into anything
else) was that if a freeze was said to begin on a particular date, then
it was to begin that date, given some appropriate time zone slack of
course. That is, if a freeze was said to begin on Monday 8th, then we
would start gradually enforcing the freeze when Monday 8th would no
longer be, in any time zone of the world.
(If release team expected that any GNOME release that would affect
freezes would not be made in time, then the release team would punt the
freeze dates accordingly, and announce it.)

Note that this definition does not include the concept of module
releases at all; if a module hasn't made a release in time, then bad
luck for them regarding the freezes, if the freeze is otherwise still in
effect, IMHO. Most translators do not follow module releases at all, and
most have not any interest nor any resources to track hundreds of
software releases to know if the individual modules can be expected to
have entered string freeze or not.
String freeze is and should be an all-or-nothing thing to be in any way
practical. If we can't enforce and expect string freeze across the whole
module set from a particular date, then we might as well just scrap the
whole string freeze thing completely, since the trackability (and hence
usefulness) of it would be hardly worth it anymore. At least not for
translators.


Christian