Proposed Release Plan changes

Magnus Melin mkmelin+mozilla at iki.fi
Thu Aug 9 06:25:21 UTC 2012


On 9.8.2012 02:41, Joshua Cranmer wrote:
> 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?

I've been thinking along the same lines as Joshua. Not following the same 
release schedule as Firefox will be very painful. It's not that we can 
actually deliver so much new features every 6 weeks that we have to release, 
but doing something different from what mozilla-central does goes against the 
natural flow, and that hurts a lot.

Doing releases is likely more work than one would guess from the outside, but 
doing so could still be money well spent. If we absolutely can't do full rapid 
releases, I'd still propose we have those releases as some kind of blessed 
builds (hey, even nightlies auto-update!), but make more noise about the 
ESR-based releases. From a community engagement perspective it's indeed very 
bad if the time until your contribution is live grows further.

  -Magnus



More information about the tb-planning mailing list