<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 18/09/2012 17:03, Kent James wrote:<br>
</div>
<blockquote cite="mid:50589B36.3070609@caspia.com" type="cite">
<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">
<div class="moz-cite-prefix">On 9/14/2012 9:30 PM,
Unicorn.Consulting wrote:<br>
</div>
<blockquote cite="mid:50582CAB.1050401@mozilla.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: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>
</blockquote>
</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>
</blockquote>
I can understand the concern, but I don't believe it is really
critical to ESR. Despite our mentions about testing the changes, I'm
pretty sure some organizations won't start widely testing until the
next ESR is actually released. So if there are issues that affect
them specifically, they may not get reported until we release the
ESR. If we delayed releasing that ESR for a couple of point
releases, then they would be in the case where the old ESR version
would be unsupported, but they might not be able to upgrade to the
new version due to the issues.<br>
<br>
The overlap is there for exactly this reason - upgrade straight away
if you can, but if not, you've got 12 weeks to resolve any issues
(or get us to resolve them).<br>
<br>
<blockquote cite="mid:50589B36.3070609@caspia.com" type="cite">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>
</blockquote>
Something else to point out here I think, is that when we release
ESR 17.0, only syadmins that choose to upgrade their uses to the new
ESR version will do so. As there will be two more ESR 10.0 releases
(one in sync with ESR 17, the second in sync with 17.0.1), I don't
see us prompting 10.0 users to do a major upgrade until 17.0.2 is
released and 10.0.x is obsolete.<br>
<br>
<blockquote cite="mid:50589B36.3070609@caspia.com" type="cite"> 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>
</blockquote>
Just as an example, for specifically for an ESR, we might want to
have an option whereby sysadmins can choose that Thunderbird does
not automatically remove the menubars (most sysamdins have set-ups
that allow them to set default prefs etc). We've done <a
href="https://developer.mozilla.org/en-US/docs/Thunderbird/Deploying_Thunderbird_in_the_Enterprise/Thunderbird_Preferences_Relevant_to_Enterprises">this
type of thing before</a> for them and it may be appropriate here.<br>
<br>
Mark.<br>
</body>
</html>