Proposed Release Plan changes

Joshua Cranmer pidgeot18 at gmail.com
Wed Aug 8 23:41:09 UTC 2012


On 8/8/2012 5:36 PM, Mark Banner wrote:
> Hi All,
>
> I just updated the Change of Release and Governance model 
> <https://wiki.mozilla.org/Thunderbird/Proposal:_New_Release_and_Governance_Model> 
> 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:
>
> https://etherpad.mozilla.org/tb-releases
>
> Sorry for no pretty pictures, I'll put one together after we flesh it 
> out a bit more.
>
> Please add small comments there, and if you think your comment needs a 
> larger discussion, use this thread or start a new one.

This definitely merits larger discussion, since I'm kind of attacking 
the core idea here...

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

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.

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.

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):
1. What are the perceived pros and cons by not adopting the rapid 
release model?
2. Under this model, who decides what gets ported to ESR-based release?
3. Under this model, who actually ports the features to ESR-based release?
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?
5. Under this model, what would happen if a highly-valued feature arose 
that relied on a change in Gecko since the last ESR?

-- 
Joshua Cranmer
News submodule owner
DXR coauthor

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/tb-planning/attachments/20120808/a04be29f/attachment.html>


More information about the tb-planning mailing list