Proposed Release Plan changes

Mark Banner mbanner at mozilla.com
Fri Aug 10 12:57:47 UTC 2012


On 09/08/2012 06:18, Ludovic Hirlimann wrote:
> so
>>
>>   * All releases will be based on Gecko ESR releases
>>
>>   * To provide a more stable core for releases, so that we're not
>>     affected so much by Gecko changes
>>
>>   * The ESR model will remain the same, separate from the mainstream
>>     channel
>>
>
> Hum why that besides the channel change they'd be identical, I don't 
> see the need to keep two channels with the same product. What's the 
> point in keeping ESR and release based on the same ESR code ?

Keeping them separate gives the opportunity for intermediate releases if 
we have a significant amount of features ready. If we didn't have 
separate channels, then we wouldn't be able to do those intermediate 
releases because we'd be breaking the ESR promise. As we don't yet know 
the amount of contributions that we'll get going forward I feel it would 
be better to keep the opportunity available rather than take it away. We 
can always review it in a year or two.

> I don't see the point keeping Aurora and Beta. From the way it 
> currently works we don't benefit much from having Aurora and Beta - 
> most Major regression are found at release time not on Aurora nor beta 
> and if they are they are found too close to the release dates to be 
> actionable. Maintaining Aurora is too time consuming in terms of QA, 
> release management and engineering for US to keep. I do see the l10 
> arguments but I think we can do it in another way (eg anyway most of 
> the l10n strings from gecko we'll get for free from Ff).
Having Aurora will give us an additional slightly-stable channel, but 
also my main argument would be for L10n - it is where they work from 
now, and I don't think that it is something worth changing. It also 
gives them stability, clear checkin needs, and continuous integration 
rather than big spurts of Thunderbird strings when we decide it is 
necessary for a release, that something that is much easier to work 
with, and it has certainly seemed a lot easier to get localisations 
complete under the rapid release scheme, especially with the improved 
tools to have now that work with the rapid release model.

 From a release management and engineering perspective, I've never found 
EarlyBird/aurora really time consuming. The builds are there and they 
run when necessary, whilst it consumes some resources, it is no where as 
near significant as trunk.

> I'de like us to consider the following :
>
>   * We base release on ESR
>   * When we have enough "new features"+bug fixes we cut a beta
>   * Beta get's tested and released over a 3/4 week period
>   * Next beta comes out a few months later which gives us time to chew
>     on beta data (bugs, feedback etc ...)
>
The problem I see here, is that this gives us a semi-random time as to 
when releases occur, which makes planning for everyone a lot harder. 
Additionally, if you're looking at a month-cycle for a beta, then I 
think you'll soon start hitting the place where to get a few betas, 
you'll actually then be hitting the preparation cycle for the next ESR 
based release.

> What I'm proposing looks a lot like what happened for 3.0 or 3.1 eg 
> reverting back to pre rapid release. I think this works better with 
> how I see Thunderbird evolving and will give us more stable releases.
The problem there is that there is a lot more co-ordination to do with 
50+ l10n teams for getting the Thunderbird strings localised and in the 
right place at the right time. Keeping Earlybird/aurora gives us that 
with relatively low cost.

Mark.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/tb-planning/attachments/20120810/ac092d82/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/20120810/ac092d82/attachment.p7s>


More information about the tb-planning mailing list