draft Thunderbird 3.1 schedule

[Dan Mosedale]

[Note that replies are being directed to the dev-apps-thunderbird list]

I've drafted a schedule for Thunderbird 3.1:

https://wiki.mozilla.org/Thunderbird:Thunderbird3.1

Some things to note:

* String and features freezes for this release are targeted at the end
of beta 1. If anyone expects to land a feature with > 20 or so strings,
please contact me (dmose) ASAP so that I can coordinate with
localization teams sooner rather than later.

* I've switched from the M1/M2-style milestone naming previously
proposed back to the alpha/beta style naming as a result of previous
discussion here. I think being more approachable from the outside has
higher value to the project than I had considered.

Thoughts/feedback? Do the dates proposed make sense? Do they collide
in any important ways with holidays observed by sizable numbers of
contributors?

Dan

[Axel Hecht]

What does "slushy" freeze mean? I see that this is just code, and if a
fix needs to happen, it will land. But I guess it'd be good to have some
"only over this schedule's dead body" freeze date, too.

Axel

[Dan Mosedale]

On 12/18/2009 7:46 AM, Axel Hecht wrote:
> On 18.12.09 07:35, Dan Mosedale wrote:
>> [Note that replies are being directed to the dev-apps-thunderbird list]
>>
>> I've drafted a schedule for Thunderbird 3.1:
>>
>> https://wiki.mozilla.org/Thunderbird:Thunderbird3.1
>

> What does "slushy" freeze mean? I see that this is just code, and if a
> fix needs to happen, it will land. But I guess it'd be good to have
> some "only over this schedule's dead body" freeze date, too.

I chose to add the word slushy there specifically to convey exactly what
you just said: that if a fix needs to happen, that it should land, and
that that date specifically didn't mean "only over this schedule's dead
body". That said, I would like us to be pretty conservative about what
we take after that date. I'm not really convinced a second deadline
helps us that much. My current inclination is to leave the single
deadline. I could simply get rid of the word "slushy" if it adds more
confusion than clarity.

Thoughts?

Dan

[Dan Mosedale]

On 12/18/2009 1:44 PM, Simon Paquet wrote:
> As axel said, the "slushy" thing just adds confusion. Either just make it a hard freeze or add another release milestone for a firm code freeze date. For strings we should just have one freeze date for each release as we've historically sucked with keeping the slushy string freeze every time.

Sold. I've removed the "slushy" verbiage entirely.
> TB 3.1RC1 has a string freeze date, even though the overall release
> string freeze already happens at 3.1b1. That doesn't make sense to me.

Indeed; that was a mistake. Fixed.
> I'd also appreciate it if developers do not only contact you in case of larger string landings, but me as well since I used to do the l10n
> coordination. Unless you want to take over, of course?

Goodness, no, and I didn't mean to imply that either. I've changed the
wiki page to include both of our names & email addresses.

Thanks for the comments!

Dan