Fwd: TB Summary of release discussion

Kent James kent at caspia.com
Tue Sep 11 22:13:40 UTC 2012


At the recent Thunderbird summit in Warsaw, there were discussions about 
the future release cycle of Thunderbird. Wayne prepared the attached 
spreadsheet trying to summarize this complex subject, and there are also 
some meeting notes available at https://etherpad.mozilla.org/qIkqbtHTSV 
I'm going to try to clarify the discussion some, and reflect some 
understandings as well from an IRC discussion that we had today.

As a general summary, there are a number of parallel issues.

1) Rate of release of feature editions (mapped to Wayne's options)

Option 0: Currently, we do one release per six-week Gecko cycle/7 
releases per ESR cycle.This is not going to happen beyond TB 17.

Option A: We only do ESR releases (1 release per ESR cycle)

Option B: We do 2 releases per ESR cycle. (This is the level of release 
that Mozilla commits to providing staff support for).

(not discussed by Wayne): We do more than two releases per ESR cycle. 
Standard8 in earlier memos discussed this as an option that would be 
possible with "community support". From the development perspective, the 
main issue is whether we allow intermediate releases at all, so if we do 
option B) it is only a resource question whether to add more 
intermediate releases in the future. So I will redefine B) to mean "two 
or more releases per ESR cycle".

Wayne listed an option C) and D) that mentioned some additional issues 
here, but in IRC we clarified those issues. This obsoletes the concept 
of a separate C) and D) option, and the issues discussed in C) and D) 
are discussed in the various issues below.

If we choose option A), then most other issues go away. That is, new 
work is landed on central (following current Gecko), 
central->aurora->beta->release transitions occur as now every 6 weeks 
(but the release channel does not get updated from the release repo 
every six weeks). The rate of new beta on the beta channel is reduced to 
about once per Gecko cycle except as we approach TB 24, when that rate 
may increase. The current release channel is identical to the current 
esr channel, but is maintained only to allow us to reconsider this 
decision later.

Assuming though that we choose B) and allow intermediate releases, a 
number of additional issues come up:

2) What Gecko repository do we use for intermediate feature releases?

Earlier there was some discussion about not using the Gecko ESR 
repository. I think there is a consensus that using the ESR Gecko 
repository for all future releases is the only viable approach.

3) Do we create a separate parallel intermediate feature branch only on 
demand and then backport desired features with an a+ patch approval, or 
do we create this branch immediately and land most new features 
simultaneously on both trunk and on the release branch (probably without 
needing an a+ approval initially)?Let me use an "fr" suffix for the 
feature release branch.

If we do the "create immediately" option, it seems to me the repo and 
channel flows would go like this:

central-fr ==> aurora-fr ==> beta ==> release
                                |        |
                                |        -> release update channel
                                -> beta update channel

central ==> aurora
    |            |
    |            -> aurora update channel (daily)
    -> daily update channel (daily)

After the last intermediate release, we abandon central-fr && aurora-fr, 
and update aurora==>beta

I'm less clear of the "on demand" variation. Perhaps like this:

central ==> aurora ==> beta (with l10n complete) => release
    |            |
    |            -> aurora update channel
    -> daily update channel

comm-fr is created on demand from comm-esr. Patches with a-tb-next+ are 
landed. It might be good to have an additional channel with completed 
localization, maybe earlybird-l10n, which would come from the beta

comm-fr
  |   |
  |   -> release update channel
  |-> beta update channel

DISCUSSION:

It seems to me that in either case, there is a serious deterioration in 
the available testing channels at a time when our paid staff support for 
support and QA will be dramatically reduced. In both options, there is 
no prior testing of the beta channel on the immediately upstream repo, 
so that channel will be less stable than in the past, which will drive 
testers away.

I think that we are going to be hard pressed to keep up with quality in 
the new model in any case. One path to failure would be if future 
releases start to have serious bugs and regressions. That would kill us 
faster than slow release of features.So I think that the quality risk, 
as well as the extra effort, of the intermediate feature release is not 
worth the benefit. I would rather encourage early adopters to use a beta 
channel which has new features instead, and maintain a stable product at 
release.

In either case, SeaMonkey would I assume use the release repo for their 
releases. The new model gives them the possibility to approve patches 
for that channel independently of TB, except near ESR releases.

:rkent

-------- Original Message --------
Subject: 	TB Summary of release discussion
Date: 	Fri, 07 Sep 2012 21:14:38 -0400
From: 	Wayne Mery <wayne.mery at gmail.com>



Attached please find spreadsheet summarizing, I hope, all the options
and very compactly the issues, pros and cons.  I have not attempted to
include all comments for reasons of space, but they are very nicely
noted in the etherpad https://etherpad.mozilla.org/qIkqbtHTSV by our
wonderful note takers. Thanks to Kent and Mark who went over an early draft.

If I have missed any options or any important issues in the summary
please let me know and I will amend the document.

W.




-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/tb-planning/attachments/20120911/319d8c7e/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: tb release options summary.xls
Type: application/vnd.ms-excel
Size: 23552 bytes
Desc: not available
URL: <http://mail.mozilla.org/pipermail/tb-planning/attachments/20120911/319d8c7e/attachment.xls>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: tb release options summary.pdf
Type: application/pdf
Size: 103380 bytes
Desc: not available
URL: <http://mail.mozilla.org/pipermail/tb-planning/attachments/20120911/319d8c7e/attachment.pdf>


More information about the tb-planning mailing list