<html>
<head>
<meta http-equiv="content-type" content="text/html; charset=ISO-8859-1">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<tt>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
<a class="moz-txt-link-freetext" href="https://etherpad.mozilla.org/qIkqbtHTSV">https://etherpad.mozilla.org/qIkqbtHTSV</a> I'm going to try to
clarify the discussion some, and reflect some understandings as
well from an IRC discussion that we had today.</tt><tt><br>
</tt><tt><br>
</tt><tt>As a general summary, there are a number of parallel
issues.</tt><tt><br>
</tt><tt><br>
</tt><tt>1) Rate of release of feature editions (mapped to Wayne's
options)</tt><tt><br>
</tt><tt><br>
</tt><tt>Option 0: Currently, we do one release per six-week Gecko
cycle/7 releases per ESR cycle.</tt><tt> This is not going to
happen beyond TB 17.<br>
</tt><tt><br>
</tt><tt>Option A: We only do ESR releases (1 release per ESR cycle)</tt><tt><br>
</tt><tt><br>
</tt><tt>Option B: We do 2 releases per ESR cycle. (This is the
level of release that Mozilla commits to providing staff support
for).</tt><tt><br>
</tt><tt><br>
</tt><tt>(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".</tt><tt><br>
</tt><tt><br>
</tt><tt> 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.</tt><tt><br>
</tt><tt><br>
</tt><tt>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.</tt><tt><br>
</tt><tt><br>
</tt><tt>Assuming though that we choose B) and allow intermediate
releases, a number of additional issues come up:</tt><tt><br>
</tt><tt><br>
</tt><tt>2) What Gecko repository do we use for intermediate feature
releases?</tt><tt><br>
</tt><tt><br>
</tt><tt>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.</tt><tt><br>
</tt><tt><br>
</tt><tt>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)?</tt><tt> Let me use an "fr" suffix for the feature
release branch.<br>
</tt><tt><br>
</tt><tt>If we do the "create immediately" option, it seems to me
the repo and channel flows would go like this:</tt><tt><br>
</tt><tt><br>
</tt><tt>central-fr ==> aurora-fr ==> beta ==> release</tt><tt><br>
| |<br>
| -> release update
channel<br>
-> beta update channel<br>
</tt><tt><br>
</tt><tt>central ==> aurora</tt><tt><br>
| |<br>
| -> aurora update channel (daily)<br>
</tt><tt> -> daily update channel (daily)<br>
<br>
After the last intermediate release, we abandon central-fr
&& aurora-fr, and update aurora==>beta<br>
<br>
I'm less clear of the "on demand" variation. Perhaps like this:<br>
<br>
</tt><tt><tt>central ==> aurora ==> beta (with l10n complete)
=> release</tt><tt><br>
| |<br>
| -> aurora update channel<br>
</tt><tt> -> daily update channel</tt><br>
<br>
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<br>
<br>
comm-fr<br>
| |<br>
| -> release update channel<br>
|-> beta update channel<br>
<br>
</tt><tt>DISCUSSION:<br>
<br>
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.<br>
<br>
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.</tt><tt>
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.<br>
<br>
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.<br>
<br>
:rkent</tt><br>
<div class="moz-forward-container"><tt><br>
</tt><tt>-------- Original Message --------</tt>
<table class="moz-email-headers-table" border="0" cellpadding="0"
cellspacing="0">
<tbody>
<tr>
<th valign="BASELINE" align="RIGHT" nowrap="nowrap"><tt>Subject:
</tt></th>
<td><tt>TB Summary of release discussion</tt></td>
</tr>
<tr>
<th valign="BASELINE" align="RIGHT" nowrap="nowrap"><tt>Date:
</tt></th>
<td><tt>Fri, 07 Sep 2012 21:14:38 -0400</tt></td>
</tr>
<tr>
<th valign="BASELINE" align="RIGHT" nowrap="nowrap"><tt>From:
</tt></th>
<td><tt>Wayne Mery <a class="moz-txt-link-rfc2396E" href="mailto:wayne.mery@gmail.com"><wayne.mery@gmail.com></a></tt></td>
</tr>
</tbody>
</table>
<tt><br>
</tt><tt><br>
</tt>
<pre>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 <a class="moz-txt-link-freetext" href="https://etherpad.mozilla.org/qIkqbtHTSV">https://etherpad.mozilla.org/qIkqbtHTSV</a> 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.
</pre>
<br>
<br>
</div>
<tt><br>
</tt>
</body>
</html>