Why don't we use Mozilla ESR in Precise?

Chris Coulson chrisccoulson at ubuntu.com
Tue Feb 7 10:57:26 UTC 2012


On 06/02/12 17:55, Micah Gersten wrote:
> On 02/06/2012 05:49 AM, Jo-Erlend Schinstad wrote:
>> On 06. feb. 2012 10:22, Jason Warner wrote:
>>> Hi All -
>>>
>>> Firefox ESR is indeed interesting, and it would seem to answer some 
>>> of the question corporations might have about Firefox, but I think 
>>> it is less interesting for Ubuntu.
>>>
>>
>> You have to understand that my original post was not meant as a 
>> proposal, but as an open question. If Ubuntu now prefers the rapid 
>> release pace of Firefox and Thunderbird, then it doesn't bother me 
>> that much. But it does represent a shift in strategy. 10.04 has used 
>> 3.6 until very recently when it became unsupported. The reason that 
>> was given for not upgrading it, was the SRU process. The reason that 
>> was given for starting to upgrade Firefox in a rapid pace afterwards, 
>> was that Mozilla had changed their support strategy and that it 
>> wouldn't be feasible to backport the necessary security patches to 
>> old versions. But now, Mozilla has changed their support strategy 
>> again, making it unnecessary to circumvent the norms.
>>
>> Now this becomes a question of communication, which to me is the 
>> biggest weakness Ubuntu has that we can do something about. If this 
>> is an active decision, then I would be interested to know when it was 
>> made and why we haven't heard anything about it. This is a 
>> significant shift, and though I try to pay close attention to what's 
>> going on, it came as a complete surprise to me. I looked for 
>> blueprints, but I couldn't find any; 
>> https://blueprints.launchpad.net/ubuntu/precise?searchtext=firefox. 
>> It is bad communication, and we need to improve. I really don't like 
>> those surprises. I spend a fair amount of time writing articles and 
>> participating in discussions, in an effort to reduce some of the 
>> misunderstandings that will always be a part of FOSS. Because 
>> development is high pace and developers doesn't always have time, or 
>> even skills, to write comprehensible non-tech articles explaining why 
>> and how. When things like that suddenly changes without notice, then 
>> it can easily make what I write, wrong. In that case, my 
>> contributions, instead of being a small part of a small solution, 
>> becomes a bigger part of a big problem. I don't think I have to 
>> explain why that's demoralizing.
>>
>> Consider documentation writers. You've spent a few hours writing some 
>> paragraphs or pages explaining why Ubuntu doesn't use the newest 
>> version of Firefox. You're satisfied that your explanation really 
>> does explain and is comprehensible by anyone. That's not easy. It's 
>> hard work. So you commit. Then translators begin working on it. And 
>> translating single strings is not always that difficult, but 
>> translating an article, is. You finish two months ahead of schedule.
>>
>> But then someone makes a silent little decision, and instead of being 
>> two months ahead, you're suddenly two years outdated. Bad 
>> communication hurts both enthusiasm and the finished product. We need 
>> predictability.
>>
>> As usual, this has become much longer than I had intended. Let me 
>> finish by making a proposal. Let's use the ESR versions by default in 
>> LTS versions of Ubuntu, and add a package called something like 
>> firefox-fastpace for those who want that. This way, we don't disrupt 
>> the stability and predictability that is so attractive to those who 
>> chooses LTS versions, but also make it easy for those who do want to 
>> be on the cutting edge of the browser developments. When upgrading 
>> from an LTS to a non-LTS, the user should be asked if the ESR version 
>> should still be used, or switch to the fast pace version.
>>
>> Thanks for reading,
>>
>> Jo-Erlend Schinstad
>>
>
> There was a UDS session on this [1] which I lead.  I was originally of 
> the opinion that the ESR for LTS releases was the best course of 
> action.  However, my wise colleagues have shown me that I was 
> mistaken.  I thought it would be just like 3.6 (stable ABI, still 
> getting High/Critical fixes).  The problems are:
>
>   * High/Critical fixes will be backported only if it's not too
>     difficult (whatever that means)
>   * There are usually new security features with each rapid release
>   * No large testing base as Jason pointed out
>   * Upgrades from ESR -> ESR will also be more shocking as UI across 7
>     releases can change quite a bit
>   * No guarantee of ESR existence past year 2 (or even that long
>     depending on how you read it)
>   * No guarantee that the ESR is inherently a stable platform (meaning
>     that previously, you had a release that was frozen and bug fixed
>     for a while before it was stable, Firefox 10 was stable enough for
>     6 weeks of life, but who says it's stable enough for a year)
>   * The ever changing web, we recently migrated Lucid and Maverick to
>     Rapid Release since Flash and some websites were breaking with 3.6
>   * The browser is one of the most exploited pieces of software on
>     Linux outside of the Kernel
>   * (from Lucid Firefox 3.6 comparison) Why is Chromium so much faster?
>
> With all these reasons, it seemed clear that we don't want the ESR in 
> the LTS or any Ubuntu release.  We want to make sure that our users 
> have the best browsing experience possible.
>
> Thank you,
> Micah Gersten
> Ubuntu Security Team
> Ubuntu Mozilla Team
>
>
> [1] https://blueprints.launchpad.net/ubuntu/+spec/security-p-mozilla-lts
>
>

Hi,

Thanks for all of your comments and opinions. Of course, I support our 
decision to not offer the Firefox ESR by default in the Ubuntu LTS.  
I've tried to explain the reasons why I think that this is a good thing 
in http://www.chriscoulson.me.uk/blog/?p=111.

Regards
Chris
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/ubuntu-desktop/attachments/20120207/590e042b/attachment.html>


More information about the ubuntu-desktop mailing list