Proposal to Provide an Extended Support Release of Firefox for Managed Deployments

628 views
Skip to first unread message

Kev Needham

unread,
Sep 21, 2011, 5:13:47 PM9/21/11
to
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/ExtendedSupport:Proposal. 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)

David E. Ross

unread,
Sep 21, 2011, 5:21:47 PM9/21/11
to
Why would consumers (as compared with enterprises) not be interested in
extended support in place of frequent new versions? That is, why would
an individual not be interested in small security and stability updates
versus new versions with new capabilities. The frequency of the latter
has created problems with add-ons, localizations, etc for individuals
and not just for enterprises.

--

David E. Ross
<http://www.rossde.com/>.

Anyone who thinks government owns a monopoly on inefficient, obstructive
bureaucracy has obviously never worked for a large corporation.
© 1997 by David E. Ross

Justin Scott

unread,
Sep 21, 2011, 5:35:00 PM9/21/11
to Kev Needham
Hi Kev,

I like the proposal a lot and it seems to address the issues I've heard
from those with enterprise deployments. I didn't see much about add-on
support, so I'm curious about how that will work:

* Will ESR releases have the same application GUID as Firefox?
* If so, and if the version numbering is different, how will add-ons
indicate their compatibility?

Justin

Kev Needham

unread,
Sep 21, 2011, 5:42:13 PM9/21/11
to
On 11-09-21 5:35 PM, Justin Scott wrote:
> Hi Kev,
>
> I like the proposal a lot and it seems to address the issues I've heard
> from those with enterprise deployments. I didn't see much about add-on
> support, so I'm curious about how that will work:
>
> * Will ESR releases have the same application GUID as Firefox?

That's my intent for this proposal, yes.

> * If so, and if the version numbering is different, how will add-ons
> indicate their compatibility?

Ideally the version numbering won't be different. e.g. If we started
with Firefox 8 as the ESR, then the app version would be 8.* for that
release. The numbers I used in the diagram was just to illustrate the
release mechanics, and I'd hope that we'd call it FX ESR and follow the
appversion it's based upon.

L. David Baron

unread,
Sep 21, 2011, 5:54:17 PM9/21/11
to dev-pl...@lists.mozilla.org
On Wednesday 2011-09-21 17:13 -0400, Kev Needham wrote:
> The proposal can be viewed on the Mozilla Wiki at
> https://wiki.mozilla.org/Enterprise/Firefox/ExtendedSupport:Proposal. 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.

I think this proposal looks great; it's reflects what I was hoping
we'd do.

However, I'm confused by the use of version numbers associated with
the ESR releases. It's not clear in the proposal what, if anything,
those version numbers are intended to mean. Is the intent that
they're something that would be exposed in any way to users or Web
developers? I had hoped that what would be exposed to Firefox users
and to Web developers would be versions that correspond to the
Firefox/Gecko version numbers, more like 8, 8.1, 8.2, etc. Is the
proposal implying that's not the case?

(I'm also slightly worried about the phrase "will commit to
backporting". If we can't, will that commitment get us in trouble?)

-David

--
𝄞 L. David Baron http://dbaron.org/ 𝄂
𝄢 Mozilla http://www.mozilla.org/ 𝄂

Kev Needham

unread,
Sep 21, 2011, 6:16:05 PM9/21/11
to
On 11-09-21 5:54 PM, L. David Baron wrote:
> On Wednesday 2011-09-21 17:13 -0400, Kev Needham wrote:
>> The proposal can be viewed on the Mozilla Wiki at
>> https://wiki.mozilla.org/Enterprise/Firefox/ExtendedSupport:Proposal. 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.
>
> I think this proposal looks great; it's reflects what I was hoping
> we'd do.
>
> However, I'm confused by the use of version numbers associated with
> the ESR releases. It's not clear in the proposal what, if anything,
> those version numbers are intended to mean. Is the intent that
> they're something that would be exposed in any way to users or Web
> developers? I had hoped that what would be exposed to Firefox users
> and to Web developers would be versions that correspond to the
> Firefox/Gecko version numbers, more like 8, 8.1, 8.2, etc. Is the
> proposal implying that's not the case?

I've updated the version numbers in the images to (hopefully) better
illustrate what the releases would look like, version-wise. Hopefully a
shift-reload will make more sense.

> (I'm also slightly worried about the phrase "will commit to
> backporting". If we can't, will that commitment get us in trouble?)

I think that's a fair point. There may be a patch we can't easily
backport, and it's a use case we'll need to address and allow for. We'll
need to address that as well, and I'm hoping that case would be a rare
exception, but one that can happen.

Kyle Huey

unread,
Sep 21, 2011, 6:23:12 PM9/21/11
to Kev Needham, dev-pl...@lists.mozilla.org
On Wed, Sep 21, 2011 at 5:13 PM, Kev Needham <k...@mozilla.com> wrote:

> 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.
>

Thanks for posting this Kev, I know a ton of work went into this proposal.
I raised this issue last week, but I think it's worthy of broader
discussion:

My main concern with this is splitting our user base between the two
releases (other than this, I actually think it's a great proposal, but I'm
not sure how to get past this problem). Just as David Ross points out,
there are any number of reasons for individuals to be interested in the LTS
releases (addons that aren't compatible, locales that have dropped off the
train, websites that break when we finally hit Gecko 10 and their crappy UA
sniffing thinks they're talking to a browser from 2004 ...). People who
install Firefox on computers for their friends/families would be more likely
to install the LTS releases so that they don't have to deal with upgrade
issues every 6 weeks. If there is a way for people to slow down, some of
them will.

Given a choice between:
1) Old style: Major feature releases every 18 (or so) months, most users are
on the latest version or one version back
2) New style: Smaller releases every 6 weeks, with most users on the latest
version but some relatively small amount spread across the last N versions
(for some N > 1).
3) This proposal, with most of our users on the latest version, some small
amount spread across the last N versions, and a good chunk on the divergent
LTS release that is roughly 6 months old.

I'll let others debate #1 vs #2, but I think #3 is the definitely worst
situation for the Mozilla community. It causes the maximum fragmentation
across versions, slows down the pace at which we can move the web forward
(from delivering new stuff every 6 weeks (at least in theory, there's some
more time here for uptake/etc) to delivering stuff every 6 months),
complicates the testing matrix both for us and for third parties (web devs,
addon authors, etc), makes some trains more equal than others (potentially
leading to pressure to "get stuff in" for a given release since that will
become the LTS release), and doesn't fix any of the pain points of the rapid
release process.

In short, I think there's an inverse relationship between how well the LTS
branch aligns with our goals and how many people use it, and that's a really
perverse incentive to have.

In my ideal world, we'd wait on implementing an LTS branch until we've had a
chance to shake out the remaining pain points in the rapid release process,
but I expect the length of time necessary to do that, the need to EOL 3.6,
etc will force our hand before that can happen.

- Kyle

Jonas Sicking

unread,
Sep 21, 2011, 7:50:09 PM9/21/11
to Kyle Huey, dev-pl...@lists.mozilla.org, Kev Needham
On Wed, Sep 21, 2011 at 3:23 PM, Kyle Huey <m...@kylehuey.com> wrote:
> On Wed, Sep 21, 2011 at 5:13 PM, Kev Needham <k...@mozilla.com> wrote:
>
>> 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.
>>
>
In one sense, if people choose to use the ESR release, even though
they are not forced to due to some enterprise-like restrictions, then
we've failed at our job of making each release of Firefox be more
awesome than the last.

I.e. people should *want* to be on the latest release. If they don't,
then we have failed and we simply need to work harder on making the
experience of being on the latest release better. A good user
experience is our first and foremost goal above everything else.

I believe for the most part that is already the case for most people,
but there are definitely some areas where we need to improve to make
it true for an even larger group of people. Silent installs and better
addon-compatibility being two major areas that we need to improve.

/ Jonas

Axel Hecht

unread,
Sep 21, 2011, 8:09:55 PM9/21/11
to
My POV from l10n:

The ESR is not a realistic target to retract to for locales going out of
business. Using the version numbers from Kev's diagram, say a locale
drops out for 10. If we wanted to give the users on that locale an ESR
version, we'd have to migrate them (and their profiles) back to 8.
That's just painful. Also, it won't help us to reanimate the locale for
13, at which point the users are stuck just a few weeks later again. I
have some leads on the topic, I'll revisit that with the folks that
opted in to that discussions soon.

There might be localizers which want to ship fixes to their localization
on ESR, like we used to do on pre-4. That's mostly repo mechanics, but
I'm leaning towards making that possible, at least for as long as we
don't have overlap on ESR. Comments welcome.

Axel

Jonas Sicking

unread,
Sep 21, 2011, 8:09:45 PM9/21/11
to Kev Needham, dev-pl...@lists.mozilla.org
On Wed, Sep 21, 2011 at 2:13 PM, Kev Needham <k...@mozilla.com> wrote:
> The proposal can be viewed on the Mozilla Wiki at
> https://wiki.mozilla.org/Enterprise/Firefox/ExtendedSupport:Proposal. 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.

One thing that is not clear in the proposal is if there will be aurora
or nightly-like channels for ESR. Before we switched to the rapid
release model, we had nightly and beta channels for a given release.
I.e. there's a nightly channel for the dot-releases for 3.6, as well
as a beta channel for the dot-releases for 3.6.

We could do something similar for ESR. There could be a aurora channel
for ESR which switches users from ESR 8.0.2 to Firefox 13 aurora at
the time when Firefox 13 branches to the aurora channel. It would then
follow from Firefox 13 aurora to Firefox 13 beta, to ESR 13.0.0 to ESR
13.0.1 to ESR 13.0.2 to Firefox 18 aurora etc.

This would let web developers at the various ESR deployments an easy
way to start testing their web sites as soon as we know what the next
ESR code will look like.

/ Jonas

David Mandelin

unread,
Sep 21, 2011, 8:16:02 PM9/21/11
to
I like the general idea, but I have a few questions about the details:

- Why is it a time-based release plan? With the less frequent releases,
we may want to time it to give a good set of new features. This would
also avoid the hypothetical problem of features being rushed in before
an ESR cut.

- Why every 30 weeks? Why not 52, or 78, or any other number? Not saying
30 is wrong, it's just a bit of a magic number with no rationale given
in the proposal.

- Why cut support 12 weeks after the next ESR comes out? Again, no
rationale was given.

I am interested in hearing all the reasons, but my specific concern with
the last 2 questions is that I get the impression that IT people want to
upgrade browsers every 1-2 years. I haven't polled, so that may be
wrong. But if not, then it seems that satisfying enterprise users
requires (frequency + overlap) to be more like 104 weeks, not 42.

Dave

Christian Legnitto

unread,
Sep 21, 2011, 8:16:32 PM9/21/11
to Jonas Sicking, dev-pl...@lists.mozilla.org, Kev Needham

On Sep 21, 2011, at 5:09 PM, Jonas Sicking wrote:

> On Wed, Sep 21, 2011 at 2:13 PM, Kev Needham <k...@mozilla.com> wrote:
>> The proposal can be viewed on the Mozilla Wiki at
>> https://wiki.mozilla.org/Enterprise/Firefox/ExtendedSupport:Proposal. 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.
>
> One thing that is not clear in the proposal is if there will be aurora
> or nightly-like channels for ESR. Before we switched to the rapid
> release model, we had nightly and beta channels for a given release.
> I.e. there's a nightly channel for the dot-releases for 3.6, as well
> as a beta channel for the dot-releases for 3.6.

This is covered in the proposal in the risks section. Even if we had testers it will be nowhere near the amount we want. Currently we have 80k Firefox 3.6 beta testers and ~10k 3.6 nightly testers....not nearly enough to be confident in quality. We expect those numbers to be a lot lower for ESR.

Just like current dot releases we would anticipate having a "esr-nightly" (not really nightly anymore as the builds only happen when there are changes) and a "esr-beta" channel and would strongly request opt-in from ESR rollouts.

Thanks,
Christian

Jonas Sicking

unread,
Sep 21, 2011, 8:32:24 PM9/21/11
to Christian Legnitto, dev-pl...@lists.mozilla.org, Kev Needham
On Wed, Sep 21, 2011 at 5:16 PM, Christian Legnitto
<cleg...@mozilla.com> wrote:
>
> On Sep 21, 2011, at 5:09 PM, Jonas Sicking wrote:
>
>> On Wed, Sep 21, 2011 at 2:13 PM, Kev Needham <k...@mozilla.com> wrote:
>>> The proposal can be viewed on the Mozilla Wiki at
>>> https://wiki.mozilla.org/Enterprise/Firefox/ExtendedSupport:Proposal. 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.
>>
>> One thing that is not clear in the proposal is if there will be aurora
>> or nightly-like channels for ESR. Before we switched to the rapid
>> release model, we had nightly and beta channels for a given release.
>> I.e. there's a nightly channel for the dot-releases for 3.6, as well
>> as a beta channel for the dot-releases for 3.6.
>
> This is covered in the proposal in the risks section. Even if we had testers it will be nowhere near the amount we want. Currently we have 80k Firefox 3.6 beta testers and ~10k 3.6 nightly testers....not nearly enough to be confident in quality. We expect those numbers to be a lot lower for ESR.

I wasn't thinking about this in terms of getting testing for the
Firefox code, but rather allowing developers at the ESR-deployed
locations a way to test their website with the new ESR release as
early as possible and as simply as possible.

I agree that getting test coverage of the actual ESR release is a
problem too, but not the problem I was trying to address.

Also, during the initial Aurora and Beta releases, the ESR code and
the Firefox code will be the same, so there should be plenty of
testing there. I.e. during Firefox 13 Aurora and Firefox 13 Beta
periods in the example I gave.

> Just like current dot releases we would anticipate having a "esr-nightly" (not really nightly anymore as the builds only happen when there are changes) and a "esr-beta" channel and would strongly request opt-in from ESR rollouts.

Awesome! Though neither of these sounds like the channel I was proposing?

/ Jonas

Cheng Wang

unread,
Sep 21, 2011, 9:45:26 PM9/21/11
to
Jonas Sicking wrote:

>
> In one sense, if people choose to use the ESR release, even though
> they are not forced to due to some enterprise-like restrictions, then
> we've failed at our job of making each release of Firefox be more
> awesome than the last.
>

The amount that our support load increases around every release seems to
suggest that this is the case. From the perspective of the individual
user, if we fix 5 crashes and introduce 3 new ones, we've made Firefox
crashier because the people with the fixed crashes either left already
or it didn't affect them too bad, but the lives of the people who got
new crashes just got a whole lot worse. I'm not only saying that updates
aren't making our users happier, I'm saying that updates are actually
making users sad.

> I.e. people should *want* to be on the latest release. If they don't,
> then we have failed and we simply need to work harder on making the
> experience of being on the latest release better. A good user
> experience is our first and foremost goal above everything else.

I think stability (and not in the crashes sense) is a key to a good user
experience that we never talk about. Users don't want to learn new
features every six weeks. They don't want to wake up one morning and
try to figure out why their back button doesn't do what it used to or
why things they committed to muscle-memory don't give the same results.
The change could be amazing, but halfway through the workday on a
seemingly random Tuesday is not a good time to say "Surprise! And you
can't go back".

So I'm willing to contend that the reason I expect a lot of users to
switch to these ESR builds is not because they want extensions to work
or because of any one issue that we can fix in the future. It's simply
because Firefox works "good enough" right now and they don't want to
have to deal with change.

Analogy: Your car drives fine now, it gets you to work. Would you give
someone the keys to your garage to let someone go in and tweak it every
six weeks. Sure they may make a minor improvement but they may just
reset your radio stations, move the stick to the other side of the dash,
or worse, crash it. Wouldn't you rather just get a new, better car when
you have time to evaluate it and when you know the updates will be
significant?

Boris Zbarsky

unread,
Sep 21, 2011, 9:51:01 PM9/21/11
to
On 9/21/11 8:16 PM, David Mandelin wrote:
> I like the general idea, but I have a few questions about the details:

Answers below are my opinion, not something I've discussed with anyone.

> - Why is it a time-based release plan? With the less frequent releases,
> we may want to time it to give a good set of new features. This would
> also avoid the hypothetical problem of features being rushed in before
> an ESR cut.

A time-based plan gives managed deployments planning room. They know
exactly when the next ESR will happen, when support for the previous one
will be removed, when they need to start testing, etc.

This is especially important if their testing period is longer than our
12-week overlap between ESR releases.

> - Why every 30 weeks? Why not 52, or 78, or any other number? Not saying
> 30 is wrong, it's just a bit of a magic number with no rationale given
> in the proposal.

The tradeoff here is that the longer the ES period the more users are
using out-of-date (in terms of web facing features) browsers. In
general, that's bad for the web. On the other hand, the shorter the ES
period the more resources deployments have to spend on testing.

I believe that I've heard somewhere that the 6-month period was picked
based on specific feedback in the enterprise working group about what
people could manage in terms of update frequency. But don't quote me on
that.

> - Why cut support 12 weeks after the next ESR comes out? Again, no
> rationale was given.

The obvious tradeoff here is number of branches we have to support at
once vs giving deployments enough time to test+transition from one to
the other. Again, we'd like this to be as short as people are able to
deal with.

> I get the impression that IT people want to
> upgrade browsers every 1-2 years. I haven't polled, so that may be
> wrong. But if not, then it seems that satisfying enterprise users
> requires (frequency + overlap) to be more like 104 weeks, not 42.

I believe the goal of this proposal is not so much to "satisfy" either
us or "enterprise users" but to give a compromise that we can both live
with....

-Boris


Christian Legnitto

unread,
Sep 21, 2011, 10:19:45 PM9/21/11
to Cheng Wang, dev-pl...@lists.mozilla.org
1. The proposal specifically says we will put barriers in place to make this not happen. You may think those wont be effective but how many people are downloading 3.6? Virtually none, as they can't find it...and we didn't even try to hide it

2. The UI and interaction changes should trickle out rather than be super in your face like 3.6 -> 4 was. This concern is only mildly related to the proposal here and even then only if #1 is unsuccessful

3. Users get angry about updates. Period. We saw complaints about 6.0.1, which introduced no changes except a security fix. We saw complaints for 3.6 point releases. People complain about Mac and Windows updates. We're working on making it less painful, but I doubt it will drive people to an ESR, especially if we are successful with #1

4. Car analogies...yikes ;-)

Thanks,
Christian
> _______________________________________________
> dev-planning mailing list
> dev-pl...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-planning

Millwood

unread,
Sep 21, 2011, 10:22:20 PM9/21/11
to
Kyle Huey wrote:
> My main concern with this is splitting our user base between the two
> releases (other than this, I actually think it's a great proposal, but I'm
> not sure how to get past this problem).

If my company is typical, this has always been the case. The
organizations that ESR is for do their own software distribution. Their
uses don't get updates from Mozilla. So they are already a collection
of separate user bases.

It seems this approach has the potential of limiting the population to
two camps - the ESR group on the current ESR release, and the rest on
the current release.

Cheng Wang

unread,
Sep 21, 2011, 11:08:00 PM9/21/11
to Christian Legnitto, dev-pl...@lists.mozilla.org

> 1. The proposal specifically says we will put barriers in place to
> make this not happen. You may think those wont be effective but how
> many people are downloading 3.6? Virtually none, as they can't find
> it...and we didn't even try to hide it

I'm not saying that users will find it if we hide it, more that users will WANT it. Sure, we can make this difficult for them, but is that really what we want?

I think the comparison you want is actually how many people are sticking with Firefox 3.6,4, 5? People who download most of these versions from FTP aren't even tracked in our download numbers but there are obviously people who are fighting our updates.

>
> 2. The UI and interaction changes should trickle out rather than be
> super in your face like 3.6 -> 4 was. This concern is only mildly
> related to the proposal here and even then only if #1 is unsuccessful

No, it's 100% this proposal. We're offering a way for people to avoid UI/UX/behavior churn; I'd be surprised if they didn't take it if given the choice. If we hide that choice, that's a different story -- but we should recognize that we're deliberately hiding that choice because we think users will want to switch to it and we don't want them to, not that somehow they're preferring the rapid release version because it's a better product.

>
> 3. Users get angry about updates. Period. We saw complaints about
> 6.0.1, which introduced no changes except a security fix. We saw
> complaints for 3.6 point releases. People complain about Mac and
> Windows updates. We're working on making it less painful, but I doubt
> it will drive people to an ESR, especially if we are successful with
> #1

Indeed. People hate updates and now they can avoid some of it. If we make that transition hard/painful, people won't go there but my only point is that if we give them the choice, people are going to take lack of updates over fancy new things (which is what Jonas was arguing).

>
> 4. Car analogies...yikes ;-)

Sorry. I don't even have a car, but I wanted something that people regard as essential. You're more likely to be upset if something you rely on breaks than something you don't.

azakai

unread,
Sep 21, 2011, 9:16:59 PM9/21/11
to
On Sep 21, 3:23 pm, Kyle Huey <m...@kylehuey.com> wrote:
> My main concern with this is splitting our user base between the two
> releases

Me too.

I think we should only do this if we are ok with splitting our user
base. Because if we release an ESR version of Firefox, lots and lots
of people will use it. And who are we to tell them they are using it
"for the wrong reasons"? If it's what they want and it's useful for
them, that's their right. If it helps them with fewer updates, fewer
addon compatibility issues, etc., they will use it. And they will
install it for their family members and so forth if it makes their
lives as tech support any easier too.

Some parts in the proposal seem to be aimed at limiting such
"unintended" uses - trying to get things so only enterprises/large
organizations/etc. will use the ESR version. But I don't think those
methods will succeed, and anyhow as I said before, the real issue is
that I do not think we should be in the position of trying to get
users not to use this if we release it and they want it.

So it seems likely that if we do this, it will split our user base. We
can promote the rapid release versions more and encourage their use,
but that will do only so much, and I suspect we will end up with the
ESR version being the "normal" release in users' minds, and the rapid
release version being something in between the ESR version and the
Beta version (i.e., more stable than Beta, less stable than ESR). Or
in other words, the ESR will become another channel in front of the
current release channel: Nightly, Aurora, Beta, Rapid Release, ESR.

Are we ok with that? I don't know where I stand on it, but it seems
like where things will end up.

I realize the importance of doing something here, and I greatly
appreciate the efforts people put into this topic and this proposal in
particular. It's a complicated topic and it is obvious that a lot of
work went into this proposal. I don't have a better idea, and I
apologize for not having something more productive to say.

- azakai

Christian Legnitto

unread,
Sep 21, 2011, 11:37:11 PM9/21/11
to Cheng Wang, dev-pl...@lists.mozilla.org


On Sep 21, 2011, at 8:08 PM, Cheng Wang <c...@mozilla.com> wrote:

>
>> 1. The proposal specifically says we will put barriers in place to
>> make this not happen. You may think those wont be effective but how
>> many people are downloading 3.6? Virtually none, as they can't find
>> it...and we didn't even try to hide it
>
> I'm not saying that users will find it if we hide it, more that users will WANT it. Sure, we can make this difficult for them, but is that really what we want?

I think yes :-). Many users would love to stay on 3.0 but that doesn't mean we should accommodate. We are proposing a change in the process for enterprise user concerns. Normal user concerns are another issue.

> I think the comparison you want is actually how many people are sticking with Firefox 3.6,4, 5? People who download most of these versions from FTP aren't even tracked in our download numbers but there are obviously people who are fighting our updates.

Ok, perfect. Firefox 5 is < 10% and dropping. Firefox 4 is < 5% and dropping. 3.6 is holding steady--not increasing--only because we haven't prompted. It will drop like a rock 9 days after the Fx 7 release.

The uptake curve got steeper between 5 and 6, which means more people are updating faster. This generally dismisses the concern that as we do more updates people are holding back.

For reference, we are very close to where Firefox 4 has less users than 3.0 which is old and EOL and been around for years.

These numbers are actually good to great. We are watching this closely though...

>
>> 2. The UI and interaction changes should trickle out rather than be
>> super in your face like 3.6 -> 4 was. This concern is only mildly
>> related to the proposal here and even then only if #1 is unsuccessful
>
> No, it's 100% this proposal. We're offering a way for people to avoid UI/UX/behavior churn; I'd be surprised if they didn't take it if given the choice. If we hide that choice, that's a different story -- but we should recognize that we're deliberately hiding that choice because we think users will want to switch to it and we don't want them to, not that somehow they're preferring the rapid release version because it's a better product.

Ok, makes sense. We're not offering a choice to those users. My point is it shouldn't be a valid choice so we're not really changing behavior. This proposal is not a proxy for reverting to the old release process for all our users.

>
>> 3. Users get angry about updates. Period. We saw complaints about
>> 6.0.1, which introduced no changes except a security fix. We saw
>> complaints for 3.6 point releases. People complain about Mac and
>> Windows updates. We're working on making it less painful, but I doubt
>> it will drive people to an ESR, especially if we are successful with
>> #1
>
> Indeed. People hate updates and now they can avoid some of it. If we make that transition hard/painful, people won't go there but my only point is that if we give them the choice, people are going to take lack of updates over fancy new things (which is what Jonas was arguing).

On the ESR updates will be just as frequent, so they aren't avoiding anything except possibly the add-on incompatibility issues.

I think the point here is an ESR doesn't mean we are giving users a choice. It is a different product with different requirements and the same appid. Some users will find it compelling and hit our barriers to entry, a few will slip by. Most if not all won't notice or care.


>
>> 4. Car analogies...yikes ;-)
>
> Sorry. I don't even have a car, but I wanted something that people regard as essential. You're more likely to be upset if something you rely on breaks than something you don't.

I know, that was tongue in cheek...it was actually a good one IMHO.

Thanks,
Christian

Justin Lebar

unread,
Sep 21, 2011, 11:58:38 PM9/21/11
to Cheng Wang
> 1. The proposal specifically says we will put barriers in place to make this
> not happen. You may think those wont be effective but how many people are
> downloading 3.6? Virtually none, as they can't find it...and we didn't even try
> to hide it.

Could you elaborate on these barriers?

Given that there have been approximately UINT32_MAX stories on Slashdot about how awful our rapid-release process is, I'm concerned that we may be underestimating how hard our community might look for these builds and how loudly they might cry if they can't get them.

Suppose we had perfect barriers. Can you imagine the news stories? "Mozilla develops the Firefox LTS you've been asking for, but puts it behind a wall! Are they more closed than Android?"

If we have crummy barriers, then we fragment the user base. If we have good barriers, then people (perhaps rightly) accuse us of being closed. It's hard for me to see how we win here.

Henri Sivonen

unread,
Sep 22, 2011, 2:12:34 AM9/22/11
to dev-pl...@lists.mozilla.org
On Thu, Sep 22, 2011 at 12:13 AM, Kev Needham <k...@mozilla.com> wrote:
> The proposal can be viewed on the Mozilla Wiki at
> https://wiki.mozilla.org/Enterprise/Firefox/ExtendedSupport:Proposal

Thank you for putting this together!

I really like the plan, I'm only commenting below on stuff I doubt,
which is why this email will look negative even though I like the
plan.

It looks like an organization deploying ESR has 24-week window to deal
with change that has happened right before the Aurora cut. The first 6
weeks is Aurora during which Mozilla might actually fix Firefox-side
regressions. This means that the organization deploying ESR has maybe
the first 2 weeks of Aurora to report Firefox-side regressions to
leave Mozilla 4 weeks to fix them during Aurora. Then there's going to
be 6 weeks of beta during which Mozilla is unlikely to fix anything on
the Firefox-side but the organization deploying ESR will be hopeful
that Mozilla fixes stuff anyway. Then there's going to be 12 week when
the organization deploying ESR knows that they have to change their
systems to address regressions or they'll fall off security patch
support.

Do we have feedback from the Enterprise WG indicating that 12 weeks
(or 18 weeks if you count beta) is enough for organizations to adjust
their intranet apps?

The plan says "Public (re)distribution of Mozilla-branded versions of
the ESR will not be permitted." Do I understand correctly that this
means that Mozilla will require Fedora and Ubuntu to ship non-ESR in
order for them to get the Firefox trademark license? (I think it would
hurt us competitively if Fedora or Ubuntu shipped ESR, because users
or journalists would compare ESR with up-to-date Chrome.) Is Mozilla
really going to prohibit Ubuntu or Fedora from shipping ESR as an
optional package or prohibit RHEL from shipping ESR, though? If
Mozilla is going to prohibit that, will there be Mozilla-provided .deb
and .rpm packages? That is to say: Surely we aren't expecting large
Linux-based deployments to use tarballs. What are we expecting them to
use?

The example version numbers use the same version number slot as
chemspills. Do I understand correctly that chemspills will shift the
planned time-based ESR release numbers ahead?

Calling the product "Firefox Enterprise Edition" instead of "Firefox
ESR" might help discourage individual users from installing it.

--
Henri Sivonen
hsiv...@iki.fi
http://hsivonen.iki.fi/

Mike Ratcliffe

unread,
Sep 22, 2011, 3:33:41 AM9/22/11
to
This sounds interesting to me. A few years ago, before starting with
Mozilla, my job was to create, and help corporations distribute,
customized versions of software. We should be aware that installation
of .exe installers is very outdated and most corporations *only*
distribute .msi packages. This is because they integrate well with
modern software distribution systems (elevated privileges, self repair
etc.). No corporation that I created packages for distributed Firefox
and this was because there was no .msi package available unless they
paid somebody to create one. If you would like me to help with working
on a system for creating .msi packages I would be happy to do so.

~Mike Ratcliffe

Mike Hommey

unread,
Sep 22, 2011, 3:53:10 AM9/22/11
to Henri Sivonen, dev-pl...@lists.mozilla.org
On Thu, Sep 22, 2011 at 09:12:34AM +0300, Henri Sivonen wrote:
> The plan says "Public (re)distribution of Mozilla-branded versions of
> the ESR will not be permitted." Do I understand correctly that this
> means that Mozilla will require Fedora and Ubuntu to ship non-ESR in
> order for them to get the Firefox trademark license? (I think it would
> hurt us competitively if Fedora or Ubuntu shipped ESR, because users
> or journalists would compare ESR with up-to-date Chrome.) Is Mozilla
> really going to prohibit Ubuntu or Fedora from shipping ESR as an
> optional package or prohibit RHEL from shipping ESR, though? If
> Mozilla is going to prohibit that, will there be Mozilla-provided .deb
> and .rpm packages? That is to say: Surely we aren't expecting large
> Linux-based deployments to use tarballs. What are we expecting them to
> use?

Corollary question: are they expected to only ship the latest Firefox
version to get the trademark license for "Firefox"?

Mike

deep64blue

unread,
Sep 22, 2011, 5:45:19 AM9/22/11
to
On Sep 21, 6:23 pm, Kyle Huey <m...@kylehuey.com> wrote:
>
> Given a choice between:
> 1) Old style: Major feature releases every 18 (or so) months, most users are
> on the latest version or one version back
> 2) New style: Smaller releases every 6 weeks, with most users on the latest
> version but some relatively small amount spread across the last N versions
> (for some N > 1).
> 3) This proposal, with most of our users on the latest version, some small
> amount spread across the last N versions, and a good chunk on the divergent
> LTS release that is roughly 6 months old.
>
> I'll let others debate #1 vs #2, but I think #3 is the definitely worst
> situation for the Mozilla community.

I work in an Enterprise and also support many friends and family, from
my perspective #1 is ideal, #3 I can live with, #2 is simply not
feasible and would lead to me dropping Firefox and moving to something
like Opera.

Firefox's unique selling point is the huge range of Add-Ons - the
authors can't keep up with the rapid release cycle, it's not just a
Corporate issue and I think the problem has a much wider impact than
you imagine. #2 should read 'most of our users, albeit a smaller total
than we have had previously'.

Regards

Alan

deep64blue

unread,
Sep 22, 2011, 5:49:21 AM9/22/11
to
On Sep 21, 7:50 pm, Jonas Sicking <jo...@sicking.cc> wrote:
>
> In one sense, if people choose to use the ESR release, even though
> they are not forced to due to some enterprise-like restrictions, then
> we've failed at our job of making each release of Firefox be more
> awesome than the last.

I don't think that's a failure - I spend enough of my free time
supporting friends and family I simply don't want the hassle of an
upgrade every 6 weeks, not interested, you can make it as awesome as
you like I don't care. I want to install a Browser and leave it for a
reasonable period of time.

Alan

deep64blue

unread,
Sep 22, 2011, 6:04:56 AM9/22/11
to
On Sep 21, 10:13 pm, Kev Needham <k...@mozilla.com> wrote:
>
> I thank you in advance for your thoughts and feedback, and look forward
> to a constructive discussion.

Thanks for the work on this - it's a great proposal.

I have two concerns:-

1) Can you clarify what "Public (re)distribution of Mozilla-branded
versions of the ESR will not be permitted." - I assume this means I
can host it on a private FTP Server and install it on Friends & Family
machines from there but can't make it generally available.

2) I'm disappointed the commitment is only for a minimum of 2 ESR
releases, that's not a lot of time in the Corporate world.

Thanks again for bringing some sanity to this mess.

Alan

Mike Hommey

unread,
Sep 22, 2011, 6:16:11 AM9/22/11
to deep64blue, dev-pl...@lists.mozilla.org
Supposedly, once you installed it, it would upgrade itself
automatically, and without your friends and family notices. What bothers
me, is that this would work well if we weren't making disruptive changes
to the UI. I'm pretty convinced a lot of people, me included, are going
to be bothered with the new behaviour for the forward button currently
in Nightly.

Mike

Henri Sivonen

unread,
Sep 22, 2011, 6:44:16 AM9/22/11
to dev-pl...@lists.mozilla.org
On Thu, Sep 22, 2011 at 12:45 PM, deep64blue <al...@gameplan.org.uk> wrote:
> I work in an Enterprise and also support many friends and family, from
> my perspective #1 is ideal, #3 I can live with, #2 is simply not
> feasible and would lead to me dropping Firefox and moving to something
> like Opera.

What makes Opera's release cycle more suitable for your purposes? They
release new features pretty often, too--every four months or so, give
or take a month. They don't seem backport security fixes on desktop to
older feature releases.

Is 4 months vs. 1.5 months a critical difference? Or that they don't
break extensions? (They do seem to make UI changes.)

JP Rosevear

unread,
Sep 22, 2011, 9:27:30 AM9/22/11
to Boris Zbarsky, dev-pl...@lists.mozilla.org
On Wed, 2011-09-21 at 21:51 -0400, Boris Zbarsky wrote:
> On 9/21/11 8:16 PM, David Mandelin wrote:
> > I like the general idea, but I have a few questions about the details:
>
> Answers below are my opinion, not something I've discussed with anyone.
>
> > - Why is it a time-based release plan? With the less frequent releases,
> > we may want to time it to give a good set of new features. This would
> > also avoid the hypothetical problem of features being rushed in before
> > an ESR cut.
>
> A time-based plan gives managed deployments planning room. They know
> exactly when the next ESR will happen, when support for the previous one
> will be removed, when they need to start testing, etc.

It is also important for Mozilla to understand what the commitment for
engineering, QA, security, etc is exactly so the trade offs and costs
can be better understood.

> This is especially important if their testing period is longer than our
> 12-week overlap between ESR releases.
>
> > - Why every 30 weeks? Why not 52, or 78, or any other number? Not saying
> > 30 is wrong, it's just a bit of a magic number with no rationale given
> > in the proposal.

> The tradeoff here is that the longer the ES period the more users are
> using out-of-date (in terms of web facing features) browsers. In
> general, that's bad for the web. On the other hand, the shorter the ES
> period the more resources deployments have to spend on testing.
>
> I believe that I've heard somewhere that the 6-month period was picked
> based on specific feedback in the enterprise working group about what
> people could manage in terms of update frequency. But don't quote me on
> that.

> > - Why cut support 12 weeks after the next ESR comes out? Again, no
> > rationale was given.
>
> The obvious tradeoff here is number of branches we have to support at
> once vs giving deployments enough time to test+transition from one to
> the other. Again, we'd like this to be as short as people are able to
> deal with.

It is, but the overlap time frame is important as well because that is
when "qualification" of the new browser happens. EWG discussion
indicated 3 months may be an acceptable amount.

> > I get the impression that IT people want to
> > upgrade browsers every 1-2 years. I haven't polled, so that may be
> > wrong. But if not, then it seems that satisfying enterprise users
> > requires (frequency + overlap) to be more like 104 weeks, not 42.
>
> I believe the goal of this proposal is not so much to "satisfy" either
> us or "enterprise users" but to give a compromise that we can both live
> with....

Indeed.

-JP
--
JP Rosevear <j...@mozilla.com>
Mozilla

JP Rosevear

unread,
Sep 22, 2011, 9:33:54 AM9/22/11
to Axel Hecht, dev-pl...@lists.mozilla.org
On Wed, 2011-09-21 at 17:09 -0700, Axel Hecht wrote:
> My POV from l10n:
>
> The ESR is not a realistic target to retract to for locales going out of
> business. Using the version numbers from Kev's diagram, say a locale
> drops out for 10. If we wanted to give the users on that locale an ESR
> version, we'd have to migrate them (and their profiles) back to 8.

(Again, using Kev's diagram).

I'm not sure I follow. The ESR will launch with FF8, if a locale drops
out on 10, the ESR is fine because we should not be changing any strings
in ESR 1.1, 1.2 etc except in the very rare case of security related
string changes.

We may run into a problem when ESR 2.0 releases, because where do we
migrate too, but that is not a new problem for us.

(We could probably explicitly state no string changes except in the
security case in the proposal).

Henri Sivonen

unread,
Sep 22, 2011, 9:37:25 AM9/22/11
to dev-pl...@lists.mozilla.org
On Thu, Sep 22, 2011 at 4:27 PM, JP Rosevear <j...@mozilla.com> wrote:
> It is, but the overlap time frame is important as well because that is
> when "qualification" of the new browser happens.

What are organizations expected to do if the new version doesn't qualify?

JP Rosevear

unread,
Sep 22, 2011, 9:45:49 AM9/22/11
to azakai, dev-pl...@lists.mozilla.org
On Wed, 2011-09-21 at 18:16 -0700, azakai wrote:
> On Sep 21, 3:23 pm, Kyle Huey <m...@kylehuey.com> wrote:
> > My main concern with this is splitting our user base between the two
> > releases
>
> Me too.
>
> I think we should only do this if we are ok with splitting our user
> base. Because if we release an ESR version of Firefox, lots and lots
> of people will use it. And who are we to tell them they are using it
> "for the wrong reasons"? If it's what they want and it's useful for
> them, that's their right. If it helps them with fewer updates, fewer
> addon compatibility issues, etc., they will use it. And they will
> install it for their family members and so forth if it makes their
> lives as tech support any easier too.

Yes, this could happen. What we should consider here is how we balance
two scenarios. One which potentially "slows down the web" as you
describe above. The second is the loss of managed environments, and
potentially users and advocates in the scenario above too, that can't
keep up currently. Both impact our ability to drive the open web
forward, how much in each case is not an easy question.

> Some parts in the proposal seem to be aimed at limiting such
> "unintended" uses - trying to get things so only enterprises/large
> organizations/etc. will use the ESR version. But I don't think those
> methods will succeed, and anyhow as I said before, the real issue is
> that I do not think we should be in the position of trying to get
> users not to use this if we release it and they want it.

Yes, understanding how we approach marketing here is critical.
Someone/several someones from marketing should weigh in here.

> So it seems likely that if we do this, it will split our user base. We
> can promote the rapid release versions more and encourage their use,
> but that will do only so much, and I suspect we will end up with the
> ESR version being the "normal" release in users' minds, and the rapid
> release version being something in between the ESR version and the
> Beta version (i.e., more stable than Beta, less stable than ESR). Or
> in other words, the ESR will become another channel in front of the
> current release channel: Nightly, Aurora, Beta, Rapid Release, ESR.
>
> Are we ok with that? I don't know where I stand on it, but it seems
> like where things will end up.
>
> I realize the importance of doing something here, and I greatly
> appreciate the efforts people put into this topic and this proposal in
> particular. It's a complicated topic and it is obvious that a lot of
> work went into this proposal. I don't have a better idea, and I
> apologize for not having something more productive to say.

Dao

unread,
Sep 22, 2011, 9:58:31 AM9/22/11
to
On 22.09.2011 15:37, Henri Sivonen wrote:
> On Thu, Sep 22, 2011 at 4:27 PM, JP Rosevear<j...@mozilla.com> wrote:
>> It is, but the overlap time frame is important as well because that is
>> when "qualification" of the new browser happens.
>
> What are organizations expected to do if the new version doesn't qualify?

The expected outcome should be to identify and fix problems, not to ban
a new version.

Kev Needham

unread,
Sep 22, 2011, 10:04:09 AM9/22/11
to
On 11-09-21 8:09 PM, Jonas Sicking wrote:
> On Wed, Sep 21, 2011 at 2:13 PM, Kev Needham<k...@mozilla.com> wrote:
>> The proposal can be viewed on the Mozilla Wiki at
>> https://wiki.mozilla.org/Enterprise/Firefox/ExtendedSupport:Proposal. 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.
>
> One thing that is not clear in the proposal is if there will be aurora
> or nightly-like channels for ESR. Before we switched to the rapid
> release model, we had nightly and beta channels for a given release.
> I.e. there's a nightly channel for the dot-releases for 3.6, as well
> as a beta channel for the dot-releases for 3.6.

I think this is one of the things we need to hash out, because it
impacts a number of users. We'd like to have a pre-release channel for
the point release fixes (the aurora and beta channels for the version of
Fx the ESR is based on will suffice there, since the releases are
equivalent), and we'll be asking organizations that deploy the esr to
put a certain number of users on the pre-release channel to get some
feedback on whether a point release breaks things.

> We could do something similar for ESR. There could be a aurora channel
> for ESR which switches users from ESR 8.0.2 to Firefox 13 aurora at
> the time when Firefox 13 branches to the aurora channel. It would then
> follow from Firefox 13 aurora to Firefox 13 beta, to ESR 13.0.0 to ESR
> 13.0.1 to ESR 13.0.2 to Firefox 18 aurora etc.

The only question I'd have is would it make sense to have two channels
given the size of the updates we'd take. I'm inclined to go with a
single channel (probably an equivalent of nightlies), as the complexity
of asking these groups to participate using three different channels may
be a diminishing returns kind of problem.

> This would let web developers at the various ESR deployments an easy
> way to start testing their web sites as soon as we know what the next
> ESR code will look like.

Yup, and ideally users, too.

k

Kev Needham

unread,
Sep 22, 2011, 10:07:16 AM9/22/11
to
Ideally they will be testing on Aurora and Beta of the base release, and
will let us know of issues they encounter. It means we need to improve
messaging around what's coming, but the predictability of the release
dates will hopefully help there.

I recognize I'm making some assumptions, but I'd really like to get orgs
involved in testing proactively vs. reactively, so that qualification is
a formality.

k

Kev Needham

unread,
Sep 22, 2011, 10:12:11 AM9/22/11
to
That is my proposal, yes.

Kev Needham

unread,
Sep 22, 2011, 10:34:09 AM9/22/11
to
On 11-09-22 2:12 AM, Henri Sivonen wrote:
> On Thu, Sep 22, 2011 at 12:13 AM, Kev Needham<k...@mozilla.com> wrote:
>> The proposal can be viewed on the Mozilla Wiki at
>> https://wiki.mozilla.org/Enterprise/Firefox/ExtendedSupport:Proposal
>
> Thank you for putting this together!
>
> I really like the plan, I'm only commenting below on stuff I doubt,
> which is why this email will look negative even though I like the
> plan.
>
> It looks like an organization deploying ESR has 24-week window to deal
> with change that has happened right before the Aurora cut. The first 6
> weeks is Aurora during which Mozilla might actually fix Firefox-side
> regressions. This means that the organization deploying ESR has maybe
> the first 2 weeks of Aurora to report Firefox-side regressions to
> leave Mozilla 4 weeks to fix them during Aurora. Then there's going to
> be 6 weeks of beta during which Mozilla is unlikely to fix anything on
> the Firefox-side but the organization deploying ESR will be hopeful
> that Mozilla fixes stuff anyway. Then there's going to be 12 week when
> the organization deploying ESR knows that they have to change their
> systems to address regressions or they'll fall off security patch
> support.

I think we're going to need to be sensitive to these requests, and do
what we can to fix regressions in that period. It also means we'll need
to get in front of changes to better communicate possible breakage so
that orgs can test against them and address them quickly. I realize it's
a shift, but it's a shift that I think will become more and more
important given moves we're seeing to cloud-based apps that will require
newer browsers. That's me being super-optimistic, I know, but I think we
can help here.

> Do we have feedback from the Enterprise WG indicating that 12 weeks
> (or 18 weeks if you count beta) is enough for organizations to adjust
> their intranet apps?

It depends on the organization, and the specific application. I've
worked in orgs where a piece of critical infrastructure depended on an
application that used an Access 97 DB on a client PC in the corner of a
vacant office. Base on the feedback received to date, I felt the 12
weeks of Aurora/Beta is enough for the large majority, given the
additional 12 weeks for certification and transition. I also am a
pragmatist, and realize things are going to break, and it's something we
need to be comfortable with.

> The plan says "Public (re)distribution of Mozilla-branded versions of
> the ESR will not be permitted." Do I understand correctly that this
> means that Mozilla will require Fedora and Ubuntu to ship non-ESR in
> order for them to get the Firefox trademark license? (I think it would
> hurt us competitively if Fedora or Ubuntu shipped ESR, because users
> or journalists would compare ESR with up-to-date Chrome.) Is Mozilla
> really going to prohibit Ubuntu or Fedora from shipping ESR as an
> optional package or prohibit RHEL from shipping ESR, though? If
> Mozilla is going to prohibit that, will there be Mozilla-provided .deb
> and .rpm packages? That is to say: Surely we aren't expecting large
> Linux-based deployments to use tarballs. What are we expecting them to
> use?

We're expecting them to distribute Mozilla Firefox. The ESR is a
modified version of Firefox, and my thoughts are that it's not something
we'd approve for distribution in a public distro. The ESR is targeted at
organizations, not individuals, and for public distributions the
expectation is that they'd continue to ship Mozilla Firefox.

> The example version numbers use the same version number slot as
> chemspills. Do I understand correctly that chemspills will shift the
> planned time-based ESR release numbers ahead?

I tried to be really clear that the version numbers were used as an
example only, and follow a versioning structure that people readily
associate with point releases. The idea is that the ESR is based on a
specific version of Firefox, and that security fixes are applied as
point releases over time. So yes, if a chemspill was released, it would
increment the point release version, whatever that looks like.

> Calling the product "Firefox Enterprise Edition" instead of "Firefox
> ESR" might help discourage individual users from installing it.

Yup, but my concern there is that there are plenty of SMB, Academic, and
public institutions who manage their deployments, and I want to be
inclusive. I'm happy to take any naming suggestions that identify this
release as something that is based on Mozilla Firefox and is intended
specifically for managed deployments.

k

Boris Zbarsky

unread,
Sep 22, 2011, 10:44:54 AM9/22/11
to
On 9/22/11 10:34 AM, Kev Needham wrote:
> Yup, but my concern there is that there are plenty of SMB, Academic, and
> public institutions who manage their deployments, and I want to be
> inclusive. I'm happy to take any naming suggestions that identify this
> release as something that is based on Mozilla Firefox and is intended
> specifically for managed deployments.

"Firefox for Managed Deployments" is presumably too clunky?

"Firefox Managed Edition"?

-Boris

Pascal Chevrel

unread,
Sep 22, 2011, 11:13:28 AM9/22/11
to
Le 22/09/2011 16:34, Kev Needham a écrit :
> On 11-09-22 2:12 AM, Henri Sivonen wrote:
>> The plan says "Public (re)distribution of Mozilla-branded versions of
>> the ESR will not be permitted." Do I understand correctly that this
>> means that Mozilla will require Fedora and Ubuntu to ship non-ESR in
>> order for them to get the Firefox trademark license? (I think it would
>> hurt us competitively if Fedora or Ubuntu shipped ESR, because users
>> or journalists would compare ESR with up-to-date Chrome.) Is Mozilla
>> really going to prohibit Ubuntu or Fedora from shipping ESR as an
>> optional package or prohibit RHEL from shipping ESR, though? If
>> Mozilla is going to prohibit that, will there be Mozilla-provided .deb
>> and .rpm packages? That is to say: Surely we aren't expecting large
>> Linux-based deployments to use tarballs. What are we expecting them to
>> use?
>
> We're expecting them to distribute Mozilla Firefox. The ESR is a
> modified version of Firefox, and my thoughts are that it's not something
> we'd approve for distribution in a public distro. The ESR is targeted at
> organizations, not individuals, and for public distributions the
> expectation is that they'd continue to ship Mozilla Firefox.
>

RHEL is for Red Hat Enterprise Linux, I would have expected distros
targeting corporate desktops to be allowed to use the ESR version actually.

Pascal

Mike Hommey

unread,
Sep 22, 2011, 11:20:34 AM9/22/11
to Kev Needham, dev-pl...@lists.mozilla.org
On Thu, Sep 22, 2011 at 10:12:11AM -0400, Kev Needham wrote:
> That is my proposal, yes.

I guess I can WONTFIX or INVALID bug 555935, then.

Mike

> On 11-09-22 3:53 AM, Mike Hommey wrote:
> >Corollary question: are they expected to only ship the latest Firefox
> >version to get the trademark license for "Firefox"?
> >
> >Mike
>

WLS

unread,
Sep 22, 2011, 11:49:37 AM9/22/11
to
Firefox Enterprise Edition?

--

SeaMonkey

David E. Ross

unread,
Sep 22, 2011, 11:53:43 AM9/22/11
to
First of all, I install updates when it is convenient for me, not when
it is convenient for developers. For that, I disable any preferences
for automatic download and installation.

Then I see how the new version works for about a week or two before
installing it on my wife's PC. My wife is quite naive about computers
and the Internet, although she is becoming proficient in doing Google
searches for new dinner recipes. I need to be able to explain to her
how her use of the application might be different. By "use", I include
such very basic aspects as appearance.

This is the way it is in my house for ALL applications, not merely
Mozilla. I am not alone. You should see the uproar at the Skype forum
about the fact that the capability to disable automatic download and
installation has been removed. Skype updates are now automatic but
definitely not silent, all of which blurs the distinction between
desired applications and viruses.

--

David E. Ross
<http://www.rossde.com/>.

Anyone who thinks government owns a monopoly on inefficient, obstructive
bureaucracy has obviously never worked for a large corporation.
© 1997 by David E. Ross

Joshua Cranmer

unread,
Sep 22, 2011, 12:07:13 PM9/22/11
to
On 9/22/2011 9:34 AM, Kev Needham wrote:
> We're expecting them to distribute Mozilla Firefox. The ESR is a
> modified version of Firefox, and my thoughts are that it's not
> something we'd approve for distribution in a public distro. The ESR is
> targeted at organizations, not individuals, and for public
> distributions the expectation is that they'd continue to ship Mozilla
> Firefox.
So if a distribution provides moderate long-term support for a branch,
then they are unable to even use the ESR versions of Firefox on that
long-term supported branch? There are also distributions primarily
targeted at organizations--e.g., RHEL; should the fact that they are a
Linux distribution per se disqualify them from using an ESR version of
Firefox?

Johnathan Nightingale

unread,
Sep 22, 2011, 12:25:12 PM9/22/11
to Kev Needham, dev-pl...@lists.mozilla.org
I don't want to go point for point on the various replies here, but I wanted to address some common threads so that Kev doesn't have to do ALL the typing.

1) Won't this proposal fragment our user base?

Compared to a world where there is nothing but our mainline releases: yes, trivially. But much less so than we have historically when we supported multiple past releases, often for a year or more. This proposal makes clear the maximum extent of the lag (42 weeks ~ 9 months), and the maximum amount of concurrent maintenance (3 branches, for 12 weeks of overlap, about a quarter of the time).

2) Why these times (30 weeks, 12 weeks, &c)? Will they be enough?

Kev's been working with all of us here, as well as EWG members, to find a good balance. 30 and 12 are multiples of 6 weeks, for perhaps obvious reasons. Some ESR consumers will want much more. As an engineering manager looking at the cost of backports, I would like as little code divergence as possible. These timelines feel like a good middle ground to me, though I think Kev is quite open to discussion of the particulars.

3) Won't our users flock to ESR?

Some might. We won't market it, and our experience with old versions (like 3.6 today) shows that the vast majority of people won't, but some might. This largely goes back to question 1.

4) Won't add-on authors choose to focus only on ESR?

I'm not the add-on expert, but as an add-on author on this thread, I know I like having users, and most of the users, by a significant margin, will be on mainline releases. As in all things, I'm sure there will be some grey area, but our add-on compatibility story (through a great deal of hard work from the add-ons team and add-on authors) is getting better, so I don't foresee a tidal wave.

5) I hate updates.

Duly noted, but not really on-topic (except as it pertains to question 1 above, I guess).

J


On 2011-09-21, at 5:13 PM, Kev Needham wrote:

> 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/ExtendedSupport:Proposal. 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)


> _______________________________________________
> dev-planning mailing list
> dev-pl...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-planning

---
Johnathan Nightingale
Director of Firefox Engineering
joh...@mozilla.com

Gervase Markham

unread,
Sep 22, 2011, 12:32:08 PM9/22/11
to Joshua Cranmer
On 22/09/11 17:07, Joshua Cranmer wrote:
> So if a distribution provides moderate long-term support for a branch,
> then they are unable to even use the ESR versions of Firefox on that
> long-term supported branch? There are also distributions primarily
> targeted at organizations--e.g., RHEL; should the fact that they are a
> Linux distribution per se disqualify them from using an ESR version of
> Firefox?

It seems to me that the ESR timescales still don't match up with even
the shortest release lifecycle of any major Linux distribution. So even
with ESR, they are going to have to update to a new major version of
Firefox (or more than one) within their stable release period. So it
doesn't get them out of that problem.

Having said that, it could be that the Linux distro's customers are
people who would normally deploy the EWG. Given that, we should perhaps
try and persuade Linux distros to package both, and ship the normal one
by default, but with the EWG in the repo? Not sure how well they'd react
to that...

Gerv

Alan Milnes (GP)

unread,
Sep 22, 2011, 6:26:54 AM9/22/11
to dev-pl...@lists.mozilla.org
On 22 September 2011 11:16, Mike Hommey <m...@glandium.org> wrote:

> On Thu, Sep 22, 2011 at 02:49:21AM -0700, deep64blue wrote:
> Supposedly, once you installed it, it would upgrade itself
> automatically, and without your friends and family notices. What bothers
> me, is that this would work well if we weren't making disruptive changes
> to the UI. I'm pretty convinced a lot of people, me included, are going
> to be bothered with the new behaviour for the forward button currently
> in Nightly.
>
>
Well if there were no UI changes, no web sites that suddenly stopped
working, no websites that behaved differently, no extensions that stopped
functioning, absolutely nothing different to an end user that would be fine.
Seems highly unlikely to me though!

Alan

Mike Hommey

unread,
Sep 22, 2011, 1:37:06 PM9/22/11
to Kev Needham, dev-pl...@lists.mozilla.org
On Wed, Sep 21, 2011 at 05:13:47PM -0400, Kev Needham wrote:
> 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.

Let me start with something positive, to balance with my previous
intervention in this thread: I do think the proposal is a nice one for
its intent, which is to address the problem the rapid release poses to
large organisations, or large deployments.

I however think there's been too much focus on that particular problem,
and a complete occultation of some other problems with the rapid release.

Let me make things clear: I do understand why we came up with the rapid
release, and as a Mozillian, I do appreciate it. But I am afraid we are
unfortunately forgetting that the Mozilla ecosystem is not only Firefox
and Thunderbird, and that there is a large ecosystem of Mozilla-based
software. Or at least it used to be large. The sad reality is that it is
shrinking, and I'm afraid it will disappear into oblivion.

There are software based on our Javascript engine. There are software
based on our rendering engine. There are software based on our platform.
For all of these, some form of long support, whatever long means, is
required. Unfortunately, it doesn't look like we give a damn, and
reality is that we're losing these software in favor of v8 and webkit
(or at least some, others also gave up or were already dead, but still
working with minimal effort).

Surely, once no one else than us uses our base bricks, that won't be a
problem anymore, but do we really want that? Is the current shift
towards the web as a platform effectively putting what made Mozilla
what it is to the brink of disappearance? If so, it would be more honest
to actually put it in official words, so that these software that rely
on us can act accordingly.

Another thing that has been left out is support of older releases, and
the branding limitations coming with it. I understand this is out of
scope, but it's about time (we'll have our third rapid release in a few
days) that these are sorted out. As a point of reference, I'll just
mention that RedHat is still maintaining 1.8 or 1.8.1, I don't remember
which one exactly (FF 1.5 or 2), and Debian, 1.9 (FF 3.0). Actually, now
that I'm writing that, I realize this is just within scope: RedHat and
Debian are maintaining these for basically the same reasons the ESR
proposal came to existence. But they do for a much longer period.

I understand that we would like them to stop doing that, and to just
ship the latest and brightest. There would actually be good reasons for
them to ship ESR releases, as has been mentioned in the thread already.
As Debian maintainer, I'm actually trying to find ways to provide the
latest to users that do want it, but at the moment it's too hard to
find for most users. And there are other constraints that prevent simply
giving them the latest and brightest. For instance, a few days from the
release of Firefox 7.0, Debian testing still has version 5.0, while
version 6.0 has been in Debian unstable since its release. The
constraints are a combination of the ecosystem mentioned above and lack
of manpower. And Debian testing does not even have the constraints
Debian stable, which is still on 3.5, has (yeah, Debian, outdated
software, news at 11).

On an unrelated note, I understand that there are also downsides coming
with supporting releases for a long time. The recurring one seems to be
userbase split. As much as the proposal invites individuals not to use
these ESR releases, you can pretty much be sure a lot of people whom
they are not intended to are going to use them, and probably for reasons
completely unrelated to this proposal, such as, but not limited to,
avoiding UI changes, addons incompatibilities, etc.

We could however probably leverage this by making ESR releases prompt
for regular releases updates *by default*. In practice, the first ESR
could actually just be the exact same as the corresponding Firefox
release. Later ESR releases could be tweaked to have the normal update
channel enabled by default. Organizations deploying an ESR would only
need to switch the update channel at deployment time. I don't think
this would be too much to ask: Aren't they likely to change a whole
lot more settings than that anyways? In other words, make it so that
people that want to keep being on ESR do mean it.

Mike

PS: Nice touch with the 42 weeks.

David E. Ross

unread,
Sep 22, 2011, 1:49:15 PM9/22/11
to
On 9/21/11 2:13 PM, Kev Needham wrote [in part]:

> 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.
>

[snipped]

What I don't understand is why ESR cannot be the ONLY timeline for
releases. It would be more frequent than what was happening before the
current rapid, frequent releases. At the same time, it would give more
time to unpaid volunteers to complete component developments, update
add-ons, and provide localizations. It would also give more time for
testing. From the standpoint of user satisfaction, it would end the
complaints about too frequent updates.

Building a solid user base should not require lemming-like following the
example of Chrome. Remember, individual users at home might also be
enterprise users at work. Individual users and enterprises should be
considered together.

Steve Wendt

unread,
Sep 22, 2011, 1:54:23 PM9/22/11
to
On 9/22/2011 3:16 AM, Mike Hommey wrote:

> I'm pretty convinced a lot of people, me included, are going to be
> bothered with the new behaviour for the forward button currently in
> Nightly.

New behavior = missing? That's what it looks like here:
http://people.mozilla.com/~shorlander/ux-presentation/ux-presentation.html

Christian Legnitto

unread,
Sep 22, 2011, 1:55:53 PM9/22/11
to David E. Ross, dev-pl...@lists.mozilla.org
This is not a proposal to change the new release process. Please focus on the enterprise proposal and the explicit goals.

Thanks,
Christian

Christian Legnitto

unread,
Sep 22, 2011, 1:57:23 PM9/22/11
to Steve Wendt, dev-pl...@lists.mozilla.org
> _______________________________________________
>

It disappears when there is nothing to move forward to. Please stay on topic or start a new thread.

Thanks,
Christian

azakai

unread,
Sep 22, 2011, 2:13:38 PM9/22/11
to
On Sep 21, 8:58 pm, Justin Lebar <justin.le...@gmail.com> wrote:
> > 1. The proposal specifically says we will put barriers in place to make this
> > not happen. You may think those wont be effective but how many people are
> > downloading 3.6? Virtually none, as they can't find it...and we didn't even try
> > to hide it.
>
> Could you elaborate on these barriers?
>
> Given that there have been approximately UINT32_MAX stories on Slashdot about how awful our rapid-release process is, I'm concerned that we may be underestimating how hard our community might look for these builds and how loudly they might cry if they can't get them.
>
> Suppose we had perfect barriers.  Can you imagine the news stories?  "Mozilla develops the Firefox LTS you've been asking for, but puts it behind a wall!  Are they more closed than Android?"
>
> If we have crummy barriers, then we fragment the user base.  If we have good barriers, then people (perhaps rightly) accuse us of being closed.  It's hard for me to see how we win here.

I agree, we would be accused of being closed and controlling if we
release an ESR version but don't make it easy for non-enterprise users
to get it, given the fact that there is definite user interest.

But taking this even further, wouldn't we potentially *want* to offer
it to normal users? If we do go to all the effort to make an ESR
version - and it is is a lot of effort - and we later do some user
surveys and see that users on the ESR version are happier (due to
fewer updates and so forth), would we have a legitimate reason for
*not* offering the ESR version to normal users? This is an honest
question: No matter how much we believe in the rapid release process,
if we have two products - ESR and rapid release - and we see that one
makes users happier, how can we not promote that one more?

There are some potential reasons, like that the rapid release versions
would be more secure (something users don't notice directly, so there
isn't an immediate impact on user happiness). But we would need to
balance that against user happiness, and I don't think we can know in
advance which considerations will end up winning.

- azakai

beltzner

unread,
Sep 22, 2011, 2:46:48 PM9/22/11
to WLS, dev-pl...@lists.mozilla.org
Netscape Navigator Gold, is what I think you're all reaching for on the
name. :)

Let Firefox be Firefox. Splitting the brand won't be noticed or understood
by the end user, nor protect the brand reputation. Perhaps add a LTE or
whatever so those looking to do support can differentiate.

cheers,
mike

Christian Legnitto

unread,
Sep 22, 2011, 3:13:58 PM9/22/11
to azakai, dev-pl...@lists.mozilla.org
On Sep 22, 2011, at 11:13 AM, azakai wrote:

> On Sep 21, 8:58 pm, Justin Lebar <justin.le...@gmail.com> wrote:
>>> 1. The proposal specifically says we will put barriers in place to make this
>>> not happen. You may think those wont be effective but how many people are
>>> downloading 3.6? Virtually none, as they can't find it...and we didn't even try
>>> to hide it.
>>
>> Could you elaborate on these barriers?
>>
>> Given that there have been approximately UINT32_MAX stories on Slashdot about how awful our rapid-release process is, I'm concerned that we may be underestimating how hard our community might look for these builds and how loudly they might cry if they can't get them.


Not responding directly to you azakai, but I can't resist: "No wireless. Less space than a nomad. Lame."


>> Suppose we had perfect barriers. Can you imagine the news stories? "Mozilla develops the Firefox LTS you've been asking for, but puts it behind a wall! Are they more closed than Android?"
>>
>> If we have crummy barriers, then we fragment the user base. If we have good barriers, then people (perhaps rightly) accuse us of being closed. It's hard for me to see how we win here.
>
> I agree, we would be accused of being closed and controlling if we
> release an ESR version but don't make it easy for non-enterprise users
> to get it, given the fact that there is definite user interest.


Firefox 3.6 is out there, supported, on mozilla.org, and doesn't have the update rage or add-on pain. We don't see people opting into it. This is a non-issue if we get out in front of it, and likely a non-issue in general.


> But taking this even further, wouldn't we potentially *want* to offer
> it to normal users?


The proposal is explicitly saying no.


> If we do go to all the effort to make an ESR
> version - and it is is a lot of effort - and we later do some user
> surveys and see that users on the ESR version are happier (due to
> fewer updates and so forth), would we have a legitimate reason for
> *not* offering the ESR version to normal users? This is an honest
> question: No matter how much we believe in the rapid release process,
> if we have two products - ESR and rapid release - and we see that one
> makes users happier, how can we not promote that one more?


No. Again, users hate updates and change. If it was up to users they would have rejected Firefox 6.0.1 even though it kept them safe and secure and didn't change *anything* user-visible. Let users speak for themselves by moving to a different browser, complaining on Twitter, or filing bugs rather than offering them something that's "ok". We don't want the ESR to become IE6, dragging the web down due to tons of users and slow(er) progress.


> There are some potential reasons, like that the rapid release versions
> would be more secure (something users don't notice directly, so there
> isn't an immediate impact on user happiness). But we would need to
> balance that against user happiness, and I don't think we can know in
> advance which considerations will end up winning.


We think users will be happier in the new release process. When their HTML5 pandora works, when their browser suddenly starts using less memory, when they are protected from a new security threat due to hardening, when the fonts on their favorite webpage start displaying correctly, when their favorite site uses new HTML tech to make their experience better, when they can suddenly push their open tab to a mobile device, when some cool new demo works even though the developer says it "only works in webkit", etc. Yes, there is pain in the short term. We turned on a dime and some things need to catch up. This proposal is recognizing that enterprises likely *can't* catch up due to their unique needs and requirements.

I definitely appreciate your thoughtful emails so far, but I really want to be clear on this point to everyone in the thread:

This proposal is not a proxy for moving away from the new release process. Please, please stop treating it as such.

Thanks,
Christian

Asa Dotzler

unread,
Sep 22, 2011, 4:04:50 PM9/22/11
to
Mike Hommey wrote:

> I however think there's been too much focus on that particular problem,
> and a complete occultation of some other problems with the rapid release.


This thread is not about rapid releases. This is a specific proposal for
how to make Firefox a more viable solution for managed deployment
scenarios. Other issues with our primary release process should find a
new thread. There have been at least a couple of comments from Kev and
Johnath reiterating that.

- A

Asa Dotzler

unread,
Sep 22, 2011, 4:06:09 PM9/22/11
to
Mike Hommey wrote:
> On Thu, Sep 22, 2011 at 10:12:11AM -0400, Kev Needham wrote:
>> That is my proposal, yes.
>
> I guess I can WONTFIX or INVALID bug 555935, then.
>
> Mike

This is a proposal. This is a discussion. Please don't start making
changes based on this proposal. It's far too early for that.

- A

Robert Kaiser

unread,
Sep 22, 2011, 5:06:11 PM9/22/11