Mozilla ponders long(er)-term support releases [LWN.net]

From:		Kev Needham <kev-AT-mozilla.com>
To:		dev-planning-AT-lists.mozilla.org
Subject:		Proposal to Provide an Extended Support Release of Firefox for Managed Deployments
Date:		Wed, 21 Sep 2011 17:13:47 -0400
Message-ID:		<NsqdnZ1euYARzufTnZ2dnUVZ_gidnZ2d@mozilla.org>

Since moving to a faster release process, Mozilla understands that some
organizations are facing challenges in deploying Mozilla products in a
managed environment. The faster release cadence makes gives 
organizations a shorter period of time to certify and use new releases,
and the lack of maintenance on older releases can expose organizations
using them to security risks. Through the Enterprise Working Group (EWG)
we're working with those organizations through to determine the best way
Mozilla can help.

To that end, representatives from the Product, Engagement, Engineering,
and Release Engineering teams have taken the feedback received to date
from the EWG and other sources to create an initial proposal for an 
Extended Support Release (ESR) of Mozilla Firefox and Thunderbird. These 
proposed releases would provide organizations with additional time to 
certify and deploy new versions of Firefox while mitigating some of the 
security risks of staying on an older release. They would be targeted 
specifically at those organizations that want to deploy Firefox and 
Thunderbird in a managed environment, and would not be recommended for 
individuals outside those organizations.

The proposal can be viewed on the Mozilla Wiki at
https://wiki.mozilla.org/Enterprise/Firefox/ExtendedSuppo.... I
think it balances the needs of organization(s) that want to continue to
deploy Firefox, while allowing Mozilla to maintain a faster release
process to better deliver new features, performance enhancements and
security fixes to individual users.

The proposed ESR will require effort to maintain, and we want to gather
feedback in dev.planning from the broader Mozilla project on the
proposal and its impacts. When submitting your feedback, please consider 
how it balances our need to give individuals the best experience 
possible through our regular release process while still meeting the 
needs of organizations that deploy Mozilla software; how it affects you 
and the people you work with; and what additional clarity we can provide 
on the ideas behind the proposal.

We realize that Thunderbird in particular is a significant downstream 
consumer of the Gecko platform, which is itself influenced by Firefox's 
plans with respect to security & maintenance policies in particular. 
While sharing technology, Thunderbird is a distinct product which is 
exposed to different distinct security and market environments, and we 
don't want to assume that the discussions which have focused on Firefox 
necessarily apply as-is to Thunderbird. We will be starting a 
Thunderbird-specific discussion informed by the Firefox processes, 
please join that discussion on the tb-enterprise mailing list 
(https://wiki.mozilla.org/Thunderbird/tb-enterprise).

I'll be compiling, responding to, and evaluating the feedback received
on the ESR proposal, and will provide updates here on the go-forward 
plan, including suggested changes. I hope to be able to provide the 
project with the information it needs to take a decision on the ESR 
within the next few weeks, and would ask for your feedback as soon as 
possible. If you're not comfortable posting to the dev.planning
group, please also feel free to contact me directly.

I thank you in advance for your thoughts and feedback, and look forward
to a constructive discussion.

Kev Needham (also representing Stormy Peters and JP Rosevear)

Mozilla ponders long(er)-term support releases

Posted Sep 22, 2011 15:58 UTC (Thu) by imgx64 (guest, #78590) [Link] (3 responses)

I can't read this without thinking about Eric S. Raymond. Second worst acronym collision after Direct Rendering Manager.

Mozilla ponders long(er)-term support releases

Posted Sep 22, 2011 16:16 UTC (Thu) by tzafrir (subscriber, #11501) [Link] (1 responses)

So it's not RFC5513-compliant?

Naturally for each ESR they'll have to appoint a Release Management Secretary in charge.

TLA collisions

Posted Sep 22, 2011 19:54 UTC (Thu) by david.a.wheeler (subscriber, #72896) [Link]

And of course, you need to do this development in the Joint Working Zone.

I agree with the grandparent, "Direct Rendering Manager" is worse.

Mozilla ponders long(er)-term support releases

Posted Sep 28, 2011 17:51 UTC (Wed) by cry_regarder (subscriber, #50545) [Link]

I worked in an org a while back that had Critical Change Requests. CCRs that is. If one was filed by an ornery customer, someone would start singing

Down on the corner, out in the street,
Wily and the Poorboys are playin';
Bring a nickel; tap your feet

Cry

Mozilla ponders long(er)-term support releases

Posted Sep 22, 2011 16:02 UTC (Thu) by Otus (subscriber, #67685) [Link] (2 responses)

Does anyone know how they have arrived at the suggested 42 weeks? Couldn't find any rationale for precisely that length in any of the links.

Mozilla ponders long(er)-term support releases

Posted Sep 22, 2011 16:16 UTC (Thu) by Ed_L. (guest, #24287) [Link]

May as well. You obviously needed one anyway. :)

Mozilla ponders long(er)-term support releases

Posted Sep 23, 2011 7:45 UTC (Fri) by Duncan (guest, #6647) [Link]

Well, it's 42-weeks, with a 12-week overlap, so they're suggesting 30 weeks between ESRs (and I too find the acronym clash interesting).

Given the fact from previous articles (H-Online, etc) that they're doing six-week releases now, but considering cutting that to five, that's every fifth release now @ six weeks per, or every sixth release if they cut to five weeks.

Every fifth release makes some sense, altho IMO it'd make a bit more sense if they synced it up to 10/15/20... Perhaps they eventually will, when they cut to 5-week releases, keeping 30 weeks between and thus an extra release, until they line up, then cutting it to 25-weeks, which would line up with six month ESRs quite well, allowing for a week of slippage every six months.

They probably thought they needed some overlap, thinking two-cycles/12-weeks sounded about right, and that it ended up being 42 weeks, given the geeky significance of that number, probably solidified it.

If they do switch to five-week cycles with a week slippage allowed, thus one ESR every six months, 10 releases, two ESRs a year, they could extend the overlap to three cycles or 15 weeks, thus cutting it to 40 weeks, or about nine months of support. Allowing for the same 1 week of slippage, that'd be 41 weeks, and they could extend it another one to retain the 42-week significance.

Meanwhile, a six-month ESR cycle with support extended to ~42 weeks should work out quite well for all the semi-annual distro release cycles as well. =:^)

Duncan

Mozilla ponders long(er)-term support releases

Posted Sep 22, 2011 16:12 UTC (Thu) by geek (guest, #45074) [Link]

Does it really "makes gives?"

Dave

Mozilla ponders long(er)-term support releases

Posted Sep 22, 2011 17:27 UTC (Thu) by xxiao (guest, #9631) [Link] (4 responses)

the fast-release was an insane decision, I'm not going to run FF version 29 or something next year, it's just insane.
Still running 3.6.x and when I need new feature I use Chrome instead.

Mozilla ponders long(er)-term support releases

Posted Sep 22, 2011 18:00 UTC (Thu) by tzafrir (subscriber, #11501) [Link] (2 responses)

Chrome version 29?

Mozilla ponders long(er)-term support releases

Posted Sep 22, 2011 20:26 UTC (Thu) by xxiao (guest, #9631) [Link]

that's why I only use chrome occasionally when FF3.6.x does not work well.

looks like Ubuntu may do rolling releases, their 6-month release plus LTS is pretty nice, hope they stick to it...

Mozilla ponders long(er)-term support releases

Posted Sep 23, 2011 10:45 UTC (Fri) by nix (subscriber, #2304) [Link]

Chrome's real version number is a daily-incrementing figure anyway (currently 890). Or perhaps it's a SVN revision number. :)

Mozilla ponders long(er)-term support releases

Posted Sep 23, 2011 9:54 UTC (Fri) by mpr22 (subscriber, #60784) [Link]

I'm aesthetically dubious about the new version numbering scheme adopted by Mozilla and Google, but it does have the great advantage of being a simple monotonically-increasing value - and besides, there aren't that many projects that are good enough at maintaining version-numbering hygeine to really justify an X.Y.Z format.

Mozilla ponders long(er)-term support releases

Posted Sep 22, 2011 18:16 UTC (Thu) by yoe (guest, #25743) [Link]

42 weeks is "long term"? rotfl. I thought a year was short

Firefox LTS

Posted Sep 22, 2011 18:42 UTC (Thu) by cesarb (subscriber, #6266) [Link] (1 responses)

So, it is a Firefox LTS (like Ubuntu LTS)?

And I guess 3.6 will in practice be the first of them (given how long it has been supported already)?

Firefox LTS

Posted Sep 22, 2011 19:04 UTC (Thu) by bhassel (subscriber, #68210) [Link]

Sounds like it. The proposal suggests that the Firefox 8 or 9 release be the first ESR, with 3.6 being end-of-lifed 12 weeks after that.

Mozilla ponders long(er)-term support releases

Posted Sep 23, 2011 11:09 UTC (Fri) by jengelh (subscriber, #33263) [Link] (3 responses)

The kernel seems to have a release scheme everybody is fine with for a handful of years now: ~8 weeks interval, -stable releases, and no artificial version number bloating); there has been little need for changes, complaints are few.

Can Mozilla learn a lesson from it/take a slice from it?

Mozilla ponders long(er)-term support releases

Posted Sep 23, 2011 13:53 UTC (Fri) by slashdot (guest, #22014) [Link] (1 responses)

To be honest, the kernel nowadays uses a flat version number just like Firefox does now.

It's hidden behind "2.6." or "3.", however.

We are at around version 40 currently.

Mozilla ponders long(er)-term support releases

Posted Sep 23, 2011 15:41 UTC (Fri) by jengelh (subscriber, #33263) [Link]

>To be honest, the kernel nowadays uses a flat version number just like Firefox does now. It's hidden behind "2.6." or "3.", however.

I know, but that's precisely what the users want, if you interpret the posts on H Online forums.

Mozilla ponders long(er)-term support releases

Posted Sep 23, 2011 18:06 UTC (Fri) by Otus (subscriber, #67685) [Link]

> there has been little need for changes, complaints are few.

To be fair, they've lately changed/added to long term support.

clearly not for end users

Posted Sep 23, 2011 20:18 UTC (Fri) by jpnp (guest, #63341) [Link]

The ESR is specifically targeted at groups looking to deploy it within a managed environment. It is not intended for use by individuals, nor as a method to mitigate compatibility issues with addons or other software. Public (re)distribution of Mozilla-branded versions of the ESR will not be permitted.

This is very clearly aimed at not providing any relief to users who are unhappy with the pace of change, long term support for their extensions etc.

Mozilla ponders long(er)-term support releases

Posted Sep 24, 2011 19:21 UTC (Sat) by xtifr (guest, #143) [Link]

This may help a bit, but I still see an opportunity for a revival of Iceweasel (which is what I'm using), possibly under a different name. It was the enforced release schedule tied to the trademarks that really forced the split between Debian and the Moz folks.

Frankly, a lot of people are going to laugh at the notion that 42 weeks is long-term support. If a consortium, with support from vendors, were to offer even longer term support for specific versions (including security updates as necessary), it would probably appeal to a lot of people. But it would require a different name, since you can't use the trademarks unless you agree to update on Moz's schedule!