<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
On 9/20/2012 5:45 AM, Ludovic Hirlimann wrote:<br>
<blockquote cite="mid:505B0FD7.2010603@mozilla.com" type="cite">
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
<div class="moz-cite-prefix">On 9/20/12 1:10 AM,
Unicorn.Consulting wrote:<br>
</div>
<blockquote cite="mid:505A50F5.9060809@gmail.com" type="cite">
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
<div class="moz-cite-prefix">On 20/09/2012 12:29 AM, Kent James
wrote:<br>
</div>
<blockquote cite="mid:5059DDB4.5010107@caspia.com" type="cite">
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
<br>
<div class="moz-cite-prefix">On 9/19/2012 1:31 AM, Mark Banner
wrote:<br>
</div>
<blockquote cite="mid:505982E0.7060808@mozilla.com"
type="cite">
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
<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"><br>
</div>
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>
</blockquote>
That's a good point. I had not thought of the issues of the
overlap. <br>
<blockquote cite="mid:505982E0.7060808@mozilla.com"
type="cite"> <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>
</blockquote>
OK that's news to me, thanks for pointing that out.<br>
<br>
With this discussion, I think that I am going back to my
earlier position, that the best way to use an intermediate
release would be to release a Thunderbird 23 or 22, so that we
would get some additional user feedback on issues before we
get locked in for another year.<br>
<br>
What do you think, Matt?<br>
</blockquote>
I have no real objection.<br>
</blockquote>
So you guys aren't worried that 6 or 12 weeks would be very short
to gather feedback bubble it up and have things fixed ? I'd rather
have 20 or 21 as a target train.<br>
</blockquote>
<br>
Oh yes, I'm worried. I think I've said before that the future of
Thunderbird will be determined by Thunderbird 24, and there are
reasons to worry.<br>
<br>
But it is also true that we are constrained by resources, and
releases take a lot of resources. Also we need to see the effect of
Gecko changes to really get stable, and those arrive late. So given
those constraints, I think that we will have to see in the 20 or 21
time frame where we stand before we can decide - and also leave open
the possibility of a 24.1 if needed.<br>
<br>
But the main point in all of this is that if we can only do one or a
few intermediate releases, it is probably better to use those
releases to improve that stability of the annual release, rather
than to push features to users a little earlier.<br>
<br>
:rkent<br>
<br>
</body>
</html>