<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">On 09/08/2012 00:41, Joshua Cranmer
wrote:<br>
</div>
<blockquote cite="mid:5022F915.9020903@gmail.com" type="cite">
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
This definitely merits larger discussion, since I'm kind of
attacking the core idea here...<br>
</blockquote>
Thanks for the comments, it obviously needs a bit more explanation
as to why we're doing it this way, so here goes. I'm answering via
your simplified questions, but I'll answer point 3 now as it isn't
covered by those questions.<br>
<br>
<blockquote cite="mid:5022F915.9020903@gmail.com" type="cite"> 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>
</blockquote>
This is already the case with the ESR based on Gecko 10 - authors of
extensions already have to keep cross-compatibility if they want to
support all/both. I think there will be more stability coming in
interfaces, so I don't see this as a huge pain.<br>
<br>
<blockquote cite="mid:5022F915.9020903@gmail.com" type="cite"> 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>
</blockquote>
All features, bugs, patches will land on comm-central to begin with
(just as they do today), so that they are incorporated in the
release that next comes off comm-central. Backporting is optional.<br>
<br>
<blockquote cite="mid:5022F915.9020903@gmail.com" type="cite"> 1.
What are the perceived pros and cons by not adopting the rapid
release model?<br>
</blockquote>
<ul>
<li>Stability, we don't have significant gecko changing under us
every six weeks, nor will we have large Thunderbird changes<br>
</li>
<ul>
<li>We don't have to do so much regression testing continuously</li>
<li>There's a greater range of time where our changes can get
testing<br>
</li>
<li>Less risk of regressions that are found after each release,
so less likely to need the x.0.1 releases that we've been
seeing</li>
<li>Regressions that have been caused by gecko, don't
necessarily have to be fixed straight away before the next
cycle, but can be left to run a bit longer<br>
</li>
<li>It gives a bit more stability to extension authors and
users, as mentioned in the original announcements</li>
</ul>
<li>Releases take up a lot of time to track, prepare and release.
It isn't just developer time, there's L10n of the website,
support documents and more (which generally are a lot of
volunteer time). When you're doing releases without significant
new features, that doesn't give so much benefit.
Security/Stability releases are a lot simpler and can be pushed
out in a much simpler manner.</li>
<li>Time-to-ship features will obviously be increased, depending
on when the features land.</li>
<ul>
<li>The maximum time would be a year (or something like 42
weeks), but it is still scheduled with a definitive release
date.</li>
</ul>
</ul>
<p>There's probably a few more, but I think they are the main ones.<br>
</p>
<blockquote cite="mid:5022F915.9020903@gmail.com" type="cite"> 2.
Under this model, who decides what gets ported to ESR-based
release?<br>
</blockquote>
I expect this would be a mixture of the community (who want to back
port), and the release drivers. The release drivers (as currently)
would have the final say as they are responsible for the stability
etc.<br>
<blockquote cite="mid:5022F915.9020903@gmail.com" type="cite"> 3.
Under this model, who actually ports the features to ESR-based
release?<br>
</blockquote>
The community - typically we'd expect the person who wrote the
feature to do it, but obviously someone else could back-port it as
well.<br>
<blockquote cite="mid:5022F915.9020903@gmail.com" type="cite"> 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>
</blockquote>
Personally, I would say no. I think intermediate releases based on
ESR should only happen when there's a significant set of features
for a release. I expect we would however be looking at a slightly
less strict security/stability policy for the ESR branch, which
would allow for more fixes to be back ported.<br>
<blockquote cite="mid:5022F915.9020903@gmail.com" type="cite"> 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>
</blockquote>
If there was no-way to work around the needed Gecko change, then the
feature would have to wait until the next ESR line, which would be
less than a year.<br>
<br>
Mark<br>
</body>
</html>