Fwd: TB Summary of release discussion

Kent James kent at caspia.com
Tue Sep 18 16:03:02 UTC 2012

On 9/18/2012 1:11 AM, Mark Banner wrote:
> On 15/09/2012 06:14, Kent James wrote:
>> On 9/14/2012 9:30 PM, Unicorn.Consulting wrote:
>>> On 15/09/2012 1:42 PM, Kent James wrote:
>>>> I have an alternate proposal for the release planning.
>>>> 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.
> 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.

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.

>>> 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.
> 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 ESR FAQ 
> <http://www.mozilla.org/thunderbird/organizations/faq/> has a diagram 
> showing this overlap. Hence, this allows for the .0.1 and .0.2 releases.
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.

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.

>> 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)
> 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?

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.

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

Maybe you are doing that anyway.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/tb-planning/attachments/20120918/50ac2f53/attachment.html>

More information about the tb-planning mailing list