<html>
<head>
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">On 8/8/2012 5:36 PM, Mark Banner wrote:<br>
</div>
<blockquote cite="mid:5022DBEA.4030901@mozilla.com" type="cite">
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
Hi All,<br>
<br>
I just updated the <a moz-do-not-send="true"
href="https://wiki.mozilla.org/Thunderbird/Proposal:_New_Release_and_Governance_Model">Change
of Release and Governance model</a> wiki page with a revised
section for Releases, this links straight to a new etherpad
containing the initial version of the proposed release plan
following the switch to the new model:<br>
<br>
<a moz-do-not-send="true" class="moz-txt-link-freetext"
href="https://etherpad.mozilla.org/tb-releases">https://etherpad.mozilla.org/tb-releases</a><br>
<br>
Sorry for no pretty pictures, I'll put one together after we flesh
it out a bit more.<br>
<br>
Please add small comments there, and if you think your comment
needs a larger discussion, use this thread or start a new one.<br>
</blockquote>
<br>
This definitely merits larger discussion, since I'm kind of
attacking the core idea here...<br>
<br>
Why go through all of the effort to make release Thunderbird track
ESR instead of mozilla-release? The only significant benefit I see
is "we don't have to release every 6 weeks," while I see a number of
major downsides:<br>
1. Any feature work that gets ported to release Thunderbird can't
rely on new Gecko features. This is a category that excludes several
major important features that need Gecko changes: seamless iframes
win us scrolling headers, several MIME-related fixes; more powerful
nsITreeView support wins us bug 213945; and many of our compose
issues are actually faults of the editor in Gecko.<br>
2. Any significant change to Gecko since the last ESR creates a
major pain port in backporting patches. Some significant changes in
the past were XPCOM registration, modifications in testing
infrastructure, etc. Changes that we have to look forward to in the
near future include things like global renamings (nsnull, PRBool,
nsresult, PRInt*, etc.), potential IDL changes, and build system
reconfigurations. Many of these might be fixed by straightforward
mechanical changes, but every change introduces a small possibility
of a bug creeping in; considering that the backporting would be done
to a branch with no pre-release baking, this requires the
backporters to be extremely eagle-eyed. Note that since Thunderbird
has a lot of C++ code, we have this kinds of things anytime someone
wants to tweak m-c to remove some of the technical debt.<br>
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.<br>
4. From a community engagement perspective, the time from when a
patch is submitted to when the patch is visible to most users
suddenly becomes horrific. Right now, it takes 3-4.5 months from
commit to release. The best-case time remains at 3 months (I'm
ignoring things that land more or less simultaneously on
c-c/c-a/c-b), while the worst-case time goes to a full year (land on
the first day of Gecko 18, get released with 24).<br>
<br>
But what would be saved by tracking ESR? comm-central et al still
have to track mozilla-central (I'd estimate that, at current rates,
you'd have 30,000+ commits between ESR releases and at least 50
m-c-induced bustages too), so you're not saving work there.
comm-aurora and possibly comm-beta still serve as user-facing baking
branches, so it's not clear to me that a rapid-release-based TB is
any less stable or secure than an ESR-based release. Releasing with
new features would require somebody to inspect the feature, make
sure it's compatible with an older version of Gecko, manually
cherry-pick it and backport it across potentially a lot of breaking
changes; asking a new contributor to do this can be daunting, so I
suspect this task would fall either to a senior contributor or an
employee partially dedicated to Thunderbird, potentially increasing
the workload in an ESR-based release relative to a
rapid-release-based one. Note that I am assuming that contributors
will indeed be contributing patch fixes on a moderately regular
basis.<br>
<br>
I personally am very skeptical that this proposal, which introduces
a lot of complexity and potential pain points, is worth the
potential savings in maintenance effort.<br>
<br>
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):<br>
1. What are the perceived pros and cons by not adopting the rapid
release model?<br>
2. Under this model, who decides what gets ported to ESR-based
release?<br>
3. Under this model, who actually ports the features to ESR-based
release?<br>
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?<br>
5. Under this model, what would happen if a highly-valued feature
arose that relied on a change in Gecko since the last ESR? <br>
<pre class="moz-signature" cols="72">--
Joshua Cranmer
News submodule owner
DXR coauthor</pre>
</body>
</html>