3.1b2 plan

Dan Mosedale dmose at mozilla.org
Tue Apr 6 15:57:18 UTC 2010


  On 4/6/10 8:18 AM, bugzilla at babylonsounds.com wrote:
> Mark Banner<mbanner at mozillamessaging.com>  wrote:
>
>>> I'd still very much like to see us ship 3.1b2 very soon, a quick RC1
>>> in early May, and final at the beginning of June.  So, with that in
>>> mind, I'd like us to prepare for 3.1b2 code/string/feature freeze
>>> immediately after the migration assistant (bug 545563) and quick
>>> filter bar (bug 545955) land in the tree.  Note that part of the
>>> reason for landing them quickly is because we think it will generate
>>> more feedback, so it's entirely possible that once they land, we'll
>>> get feedback that will make us reconsider the current plan.  But at
>>> this point, particularly with regards to the filter bar, that doesn't
>>> seem particularly likely.
>> That's something we should prepare l10n for - the current plan was to do
>> the final string freeze at b2 and then release. So we ought to be aware
>> for them that we may need to land a few string changes (maybe we should
>> just treat them as late-l10n).
>   
> If we know beforehand that we will do string changes after the string freeze
> or we know that there is at least a high-probability that there will be
> string changes, then the solution is not to keep the string freeze date
> and do lots of late-l10n changes, but to adjust the string freeze date.
>   
> Late-l10n changes should be the exception and not become the rule. Ideally
> we would never do a single late-l10n change.
I believe the nature of the change that I'm proposing is consistent with 
all this.  In other words, the only real change here is that we're going 
to do the same string freeze that we've always planned to do at the end 
of b2, it's just that the end of b2 will be happening almost immediately 
after the landing.

It's true that this raises the risk of late-l10n strings a bit, but I'd 
still like to hold the line on them and really only accept them if 
they're truly things that we can't live without.

Dan




More information about the tb-planning mailing list