Thunderbird betas - proposal: move to week 2 of a cycle

Mark Banner mbanner at mozilla.com
Tue Nov 20 13:22:10 UTC 2012


On 19/11/2012 16:07, Kent James (mobile) wrote:
> On 11/19/2012 3:35 AM, Mark Banner wrote:
>> Hi All,
>>
>> With the move to the new release model, and as per the plan, we're 
>> still expecting to do new beta releases once per cycle.
>>
>> I would like to propose that we move the beta release to the second 
>> week of a gecko rapid release cycle - i.e. although Firefox would 
>> release a new gecko beta around the same time as a new release point 
>> (e.g. 18.0b1 normally comes out a day after 17.0), we'd actually wait 
>> a week before building and releasing Thunderbird 18.0b1.
>>
> I'm all in favor of moving the beta later, but I had assumed it would 
> be even later, like near the end of a rapid release cycle. I've 
> suggested that the betas be promoted as an "early adopter" version of 
> Thunderbird. If the beta is also an early adopter version, it would be 
> best to have the beta as late as possible.
I can see the argument, but I don't think that we generally gain much 
just from gecko changes over the six weeks. Whilst it is true that some 
of their crashes do affect us, I'm not sure that waiting will actually 
help us.

I think there's a balance of taking the new gecko late to give a small 
bit more stability, or getting the new gecko out earlier so that we can 
find problems in testing it that need to be fixed before the next gecko 
gets to beta, or even the trunk version gets onto aurora.

What would you think about week 3?

> Is there any chance of doing both?  My understanding was that the rate 
> of betas was being reduced to conserve resources. Since we agreed to 
> drop the mid-year full release, we are using less resources than we 
> were originally allocated.  Could we use those resources to have a two 
> beta cycle, one at the point you suggested and another at the end of 
> the rapid release cycle?
What would a second beta release at the end of a cycle gain us (except 
in the case where we had a really really critical issue in beta)? If 
would have some stability fixes in, but they would come during the next 
cycle anyway, which generally isn't far off.

Rather than having two betas a cycle, I think I'd prefer to have the 
folks not working directly on the releases to be more available to work 
with the community for co-ordination, bug tracking, bug fixing, QA etc.

Mark
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/tb-planning/attachments/20121120/b2b803e4/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4123 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://mail.mozilla.org/pipermail/tb-planning/attachments/20121120/b2b803e4/attachment.p7s>


More information about the tb-planning mailing list