String and feature freeze

bugzilla at babylonsounds.com bugzilla at babylonsounds.com
Fri Apr 23 07:54:38 UTC 2010


Dan Mosedale <dmose at mozilla.org> hat am 22. April 2010 um 22:56 geschrieben:

>>> It seems to me it would make more sense (that is spread out the load
>>> a little and also allow more bugs to land) if the feature freeze was
>>> not the same date as the string freeze, but a few days later.
>>
>> I would argue the opposite.  String freeze after non-blocker freeze. 
>> Then blockers can continue to land and we declare string freeze only
>> once all the blockers have landed so we can avoid all this late-l10n
>> stuff, but we avoid dangerous, rushed churn involving non-blockers.
>
> To be honest, I was actually surprised that sipaq suggested we use
> late-l10n the way we've been using it this week.  My own inclination
> would have been to simply declare that we had missed Tuesday as the
> string freeze date and then to slip the string freeze date, which would
> not have required late-l10n stuff.
>
> Sipaq, what are your thoughts?

 
We either have a string freeze or we don't.
 
If we have one, than any bug with string changes that lands after the
freeze is a late-l10n bug by definition.
 
Slipping the string freeze date would have been fine with me, but then
somebody would have had to tell me about it beforehand, since I'm not
the one who can decide this on his own.
 
But postponing the string freeze would have meant postponing the release
as well, since we can't just give localizers just 2-3 days to catch up
with all our changes and still expect them to test their locales thoroughly
and to give us l12y feedback in bugs where we ask for it.
 
Does that clarify things?
 
Cya
Simon



More information about the tb-planning mailing list