Proposed Release Plan changes
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
> 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:
> 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
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
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?
News submodule owner
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the tb-planning