<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<br>
<div class="moz-cite-prefix">On 9/18/2012 1:11 AM, Mark Banner
wrote:<br>
</div>
<blockquote cite="mid:50582CAB.1050401@mozilla.com" type="cite">
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
<div class="moz-cite-prefix">On 15/09/2012 06:14, Kent James
wrote:<br>
</div>
<blockquote cite="mid:50540EAB.2000605@caspia.com" type="cite">
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
<br>
<div class="moz-cite-prefix">On 9/14/2012 9:30 PM,
Unicorn.Consulting wrote:<br>
</div>
<blockquote cite="mid:50540461.5030406@gmail.com" type="cite">
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
<link href="chrome://translator/skin/floatingPanel.css"
type="text/css" rel="stylesheet">
<div class="moz-cite-prefix">On 15/09/2012 1:42 PM, Kent James
wrote:<br>
</div>
<blockquote cite="mid:50540047.4040003@caspia.com" type="cite">I
have an alternate proposal for the release planning. <br>
<br>
So my proposal is that we do "intermediate releases" to the
main release channel starting at either TB 22 or TB 23.
These would be releases from the main
central/aurora/beta/release repositories so would not need
additional repos with all of the complications of that. <br>
</blockquote>
</blockquote>
</blockquote>
Assuming these are based on the equivalent Gecko versions, then we
would also need to consider back-porting of the core security
fixes to those releases for each of the .0.1 releases.<br>
</blockquote>
<br>
At the moment I prefer Matt's proposal and not this one. But in
defense of my old position, all that I was suggesting is that we do
the "intermediate release" one or two cycles prior to the ESR
release, and that we use the same procedures that we have in place
today to do those. I would do a TB22 and TB 23 or just a TB 23. In
neither case do we need backporting, just like we don't need
backporting today - we just start the old rapid release train one or
two releases before ESR.<br>
<br>
<blockquote cite="mid:50582CAB.1050401@mozilla.com" type="cite"> <br>
<blockquote cite="mid:50540EAB.2000605@caspia.com" type="cite">
<blockquote cite="mid:50540461.5030406@gmail.com" type="cite"> I
think that an ESR release should not become an ESR release at
the same time the general release occurs. ESR is really aimed
at Business and they are in no hurry for new releases, so we
do what business has been doing for almost as long as they
have had computers, wait for the .1 release. That is there
will be a 17.1 ESR and a 24.1 ESR or whatever no time frame as
such, but released reasonably soon after the main release with
fixes as required, including a roleup of the now almost
mandatory 0.1 and 0.2. Releases. The general user base can
come along for the ride to point one, but point one is the ESR
release.<br>
</blockquote>
</blockquote>
ESR has been designed with new features at the time of the ESR
being considered. There is an overlap of 2 releases on the ESR
channel to allow organisations time to switch over and for any
critical issues to be resolved. The <a moz-do-not-send="true"
href="http://www.mozilla.org/thunderbird/organizations/faq/">ESR
FAQ</a> has a diagram showing this overlap. Hence, this allows
for the .0.1 and .0.2 releases.<br>
</blockquote>
I think that the concern that Matt and I are showing is that each
new *. release seems to come with a few new critical issues that are
not resolved until the *.0.1 or *.0.2 release. Currently ESR 17 is
the same as TB17 and has the same initial instability.<br>
<br>
Why is that needed? Why not delay the ESR release relative to the
main release until some period of time has elapsed for those
instabilities to get worked out? ESR has no rush to it.<br>
<br>
<blockquote cite="mid:50582CAB.1050401@mozilla.com" type="cite"> <br>
<blockquote cite="mid:50540EAB.2000605@caspia.com" type="cite"> So
to interpret what I think you are saying in terms of repos and
channels, we proceed with 17.0 as planned - but it is not the
ESR release. We freeze mozilla-central in comm-aurora, release,
and beta so that eventually release, beta, and aurora are all on
gecko17. New work is landed in comm-central (with current
gecko), and selected patches are landed in aurora (with a+) as
needed in 17.1 (which will also be ESR). After 17.1 releases, we
restart the central->aurora->beta migrations as now (but
no new releases until 24.0 then 24.1 ESR)<br>
</blockquote>
I think my other message to this thread covers this slightly
differently. What I think I could do with though, is a clear
statement of the problem you're trying to solve here, as this
doesn't just sound like just allowing an intermediate release of
features. Earlier in the thread you mentioned there's issues
fixing bugs due to L10n. Are these flagged as
tracking-thunderbird17? Can you also provide some examples?<br>
</blockquote>
<br>
The problem we are trying to solve is preventing the *.0.0
instabilities from hitting the ESR channel, so that ESR users do not
have to go through a period of pain before the release stabilizes.
Matt's proposal does this better than my initial proposal.<br>
<br>
The current example of a bug where potentially better fixes were not
considered due to L10n constraints is "[Bug 791311] Don't disable
the menubar for existing users", thought that is just a current
example. The more general point is that we should not let L10n
constraints prevent us from presenting ESR users with the optimal
fixes for bugs. That may or may not be an issue in the current ESR
release, if not then ESR could happen at 17.0.1 or 17.0.2<br>
<br>
Maybe you are doing that anyway.<br>
<br>
:rkent<br>
<br>
</body>
</html>