Proposed Release Plan changes

Mark Banner 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 
those questions.

> 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.

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


More information about the tb-planning mailing list