Proposed Release Plan changes

Mark Banner mbanner at mozilla.com
Mon Aug 13 10:10:01 UTC 2012


On 10/08/2012 18:44, Justin Wood (Callek) wrote:
> Mark Banner wrote:
>>> 1. What are the perceived pros and cons by not adopting the rapid
>>> release model?
>>
>>   * Stability, we don't have significant gecko changing under us every
>>     six weeks, nor will we have large Thunderbird changes
>
> CON: But you'll have larger range of changes from ESR to ESR and 
> harder to pinpoint regression ranges.
That's why we want to keep Daily, Earlybird and Beta running as much as 
possible with latest Gecko - which will help negate the "large" range of 
changes. We know that won't cover everything, but it will go a long way 
to helping.

>>       o Less risk of regressions that are found after each release, so
>>         less likely to need the x.0.1 releases that we've been seeing
>
> Increasing the timeframe, and decreasing users on a release, doesn't 
> change the RISK of regressions, it does however INCREASE the risk that 
> it won't be caught before release. And increases the pain of 
> finding/fixing the regression.
Accepted, but the point here is that we won't be likely to need to be 
doing an additional x.0.1 release every six weeks due to a completely 
new release on a new gecko, worst-case it'd be once a year.

>>       o Regressions that have been caused by gecko, don't necessarily
>>         have to be fixed straight away before the next cycle, but can be
>>         left to run a bit longer
>
> Again, Incorrect if you account for the fact that SeaMonkey is still 
> doing releases.
We have committed to producing two Thunderbird releases a year with the 
support of paid staff. We obviously want to do some betas in support of 
testing, but if the regression is not major but something we'd fix for 
final, we may choose to leave it for a bit longer. Of course, regression 
fixing isn't exclusive to paid staff, and can obviously be done by the 
community as well.

If the community wanted to do extra Thunderbird releases, or SeaMonkey 
wants to do extra releases then the people in the community responsible 
for those pieces will need to pick up the work for those releases, 
including fixing any regressions.

Mark.

-------------- 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/20120813/c5f03ce8/attachment.p7s>


More information about the tb-planning mailing list