3.1b2 plan

bugzilla at babylonsounds.com bugzilla at babylonsounds.com
Tue Apr 6 15:18:49 UTC 2010

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.
The reason is not just the additional load that this generates on the l10n
side, but the load that it generates on my end as well. if we do late-l10n
changes the amount of monitoring and inquiry activities with regards to
outstanding changes by localizers will go up significantly.

More information about the tb-planning mailing list