3.1b2 plan

[Dan Mosedale]

As per last week's messages, we now have blog posts out there
requesting feedback on our two remaining key UX features by the end of
the day Wednesday. So far, we've gotten some good feedback on the quick
filter bar, and, with luck, more will arrive on both that and the
migration assistant by Wednesday.

I'm hoping to see both up for code-review soon.

3.1b2 has already taken a bunch longer than we were hoping, and that's a
big deal because we need to get 3.1 final out so that we can offer Tb2
users a prompted major update and be able to completely let go of the
old 1.8.1 branch (Rafael will be posting more about our 2.0.0.x plans
later this week).

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.

As often happens, it's become more clear that we can't really block on
all the bugs that are still on the blocker list. I need to go through
the list again and make some hard decisions, but it's my belief that
anything that's not in the tree by the time those two bugs land is
something that we should seriously consider living without.

Also, please update the status whiteboard of any blocker bugs that you own.

Thanks!
Dan
_______________________________________________
tb-planning mailing list
tb-pl...@mozilla.org
https://mail.mozilla.org/listinfo/tb-planning

[Mark Banner]

On 06/04/2010 00:24, Dan Mosedale 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).

I think we also need to consider branching at around the time of b2 code
freeze/release as well (although this possibly needs a separate thread).
It would have helped with some of the driving decisions (push things to
trunk rather than branch) and if we do it before the b2 release, we can
make sure we've got all our configs set up right for 3.1 which would
then lead straight into 3.1.1 etc.

> As often happens, it's become more clear that we can't really block on
> all the bugs that are still on the blocker list. I need to go through
> the list again and make some hard decisions, but it's my belief that
> anything that's not in the tree by the time those two bugs land is
> something that we should seriously consider living without.

I think that's reasonable, assuming we've got time to finish reviews
etc. Getting a firm deadline would also be useful as well.

Mark.

[bugz...@babylonsounds.com]

Mark Banner <mba...@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.
 
Cya
Simon

[Dan Mosedale]

On 4/6/10 8:18 AM, bugz...@babylonsounds.com wrote:
> Mark Banner<mba...@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