Proposed Release Plan changes
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
>> 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.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 4123 bytes
Desc: S/MIME Cryptographic Signature
More information about the tb-planning