Proposed Release Plan changes
mbanner at mozilla.com
Thu Aug 9 12:01:25 UTC 2012
On 09/08/2012 00:41, Joshua Cranmer wrote:
> This definitely merits larger discussion, since I'm kind of attacking
> the core idea here...
Thanks for the comments, it obviously needs a bit more explanation as to
why we're doing it this way, so here goes. I'm answering via your
simplified questions, but I'll answer point 3 now as it isn't covered by
> 3. Everyone who wants to maintain compatibility with preview and
> release versions of Thunderbird now has to contend with the
> possibility of 8 versions of difference in Gecko (17 on m-esr versus
> 25 on m-aurora). This introduces similar issues as point #2, but it
> also applies to community extension authors as well too.
This is already the case with the ESR based on Gecko 10 - authors of
extensions already have to keep cross-compatibility if they want to
support all/both. I think there will be more stability coming in
interfaces, so I don't see this as a huge pain.
> In short, the questions I want answered are the following (I'm
> assuming that the intended landing of features is on c-c, not c-r):
All features, bugs, patches will land on comm-central to begin with
(just as they do today), so that they are incorporated in the release
that next comes off comm-central. Backporting is optional.
> 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
o We don't have to do so much regression testing continuously
o There's a greater range of time where our changes can get testing
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
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
o It gives a bit more stability to extension authors and users, as
mentioned in the original announcements
* Releases take up a lot of time to track, prepare and release. It
isn't just developer time, there's L10n of the website, support
documents and more (which generally are a lot of volunteer time).
When you're doing releases without significant new features, that
doesn't give so much benefit. Security/Stability releases are a lot
simpler and can be pushed out in a much simpler manner.
* Time-to-ship features will obviously be increased, depending on when
the features land.
o The maximum time would be a year (or something like 42 weeks),
but it is still scheduled with a definitive release date.
There's probably a few more, but I think they are the main ones.
> 2. Under this model, who decides what gets ported to ESR-based release?
I expect this would be a mixture of the community (who want to back
port), and the release drivers. The release drivers (as currently) would
have the final say as they are responsible for the stability etc.
> 3. Under this model, who actually ports the features to ESR-based release?
The community - typically we'd expect the person who wrote the feature
to do it, but obviously someone else could back-port it as well.
> 4. Is it expected that most changes (commits other than those
> necessary to fix m-c-induced issues) will get ported to ESR-based release?
Personally, I would say no. I think intermediate releases based on ESR
should only happen when there's a significant set of features for a
release. I expect we would however be looking at a slightly less strict
security/stability policy for the ESR branch, which would allow for more
fixes to be back ported.
> 5. Under this model, what would happen if a highly-valued feature
> arose that relied on a change in Gecko since the last ESR?
If there was no-way to work around the needed Gecko change, then the
feature would have to wait until the next ESR line, which would be less
than a year.
-------------- next part --------------
An HTML attachment was scrubbed...
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 4123 bytes
Desc: S/MIME Cryptographic Signature
More information about the tb-planning