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

[Kev Needham]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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

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]

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]

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

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

That is my proposal, yes.

[Kev Needham]

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]

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]

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]

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]

Firefox Enterprise Edition?

--

SeaMonkey

[David E. Ross]

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]

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]

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]

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

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]

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]

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]

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]

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]

> _______________________________________________
>

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

Thanks,
Christian

[azakai]

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]

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]

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]

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]

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]

Christian Legnitto schrieb:

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

Oh, we do. Not in masses, but still I continue to read new messages
again and again from people who want to get back to 3.x or want to stay
there because they dislike the UI of 4 onwards or have problems with
add-ons being incompatible or some other aspects of some more recent
version.

That still doesn't make me a friend of the ESR proposal, but tells me
there is a need for us to care about those people and find a way to
bring them along to newer trains.

Robert Kaiser

--
Note that any statements of mine - no matter how passionate - are never
meant to be offensive but very often as food for thought or possible
arguments that we as a community needs answers to. And most of the time,
I even appreciate irony and fun! :)

[Robert Kaiser]

Kev Needham schrieb:

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

How many resources should us people working on Mozilla (employees,
contractors, volunteer helpers) branch off of working on new releases
and channel into maintaining ESR instead?

In my personal example, I'm watching, analyzing and trying to get fixes
for crashes in latest Nightly, Aurora, Beta and Release versions, along
with other tasks like bringing the analysis tools forward, this already
often maxes out what I can do in my work time. What should I let fall on
the side to look at ESR as well? Or should I ignore ESR in my daily
work? Has the Enterprise Working Group thought about those things as well?

(I know that in the end it's my decision what I concentrate on, but I'd
like to hear your proposal of how we should split our attention there.
The same thing applies to QA, support, security, and other areas, so
this is not a one-off but a common issue for contributors of any kind.)

[Dao]

On 22.09.2011 23:17, Robert Kaiser wrote:
> In my personal example, I'm watching, analyzing and trying to get fixes
> for crashes in latest Nightly, Aurora, Beta and Release versions, along
> with other tasks like bringing the analysis tools forward, this already
> often maxes out what I can do in my work time. What should I let fall on
> the side to look at ESR as well?

Nothing.

> Or should I ignore ESR in my daily work?

Yes. The proposal states:

Mozilla will commit to backporting security bugs qualified as "Critical"
and "High" to the ESR. Other security and stability backports to the ESR
will be included at Mozilla's discretion.

[Christian Legnitto]

On Sep 22, 2011, at 2:06 PM, Robert Kaiser wrote:

> Christian Legnitto schrieb:
>> 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.
>
> Oh, we do. Not in masses, but still I continue to read new messages again and again from people who want to get back to 3.x or want to stay there because they dislike the UI of 4 onwards or have problems with add-ons being incompatible or some other aspects of some more recent version.

Yeah, I'm not saying the number is zero. I'm saying the % of people using Firefox 3.6 is not increasing so the numbers aren't substantial in the scheme of things. I expect similar behavior with an ESR. Concretely, I expect less than 500,000 non-enterprise users on an ESR and depending on the controls we put in place I would expect it to get all the way down to 5,000 or so.

> That still doesn't make me a friend of the ESR proposal, but tells me there is a need for us to care about those people and find a way to bring them along to newer trains.

This is an entirely different issue, correct? How would ESR help someone who wants their 3.6 status bar or hates tabs on top and doesn't know how to change it? It merely timeshifts the changes and bundles more together every ESR cutover, which might be even more jarring.

Thanks,
Christian

[azakai]

On Sep 22, 12:13 pm, Christian Legnitto <clegni...@mozilla.com> wrote:
>
> > 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.

I agree completely. That's the goal!

> This proposal is recognizing that enterprises likely *can't* catch up due to their unique needs and requirements.
>

I understand that, but what concerns me is that there is a distinction
between the actual ESR itself, and what we say it is meant for. What
it actually *is* is a more slowly-updating version of Firefox. What we
say it is *for* is for enterprises.

The consequences of that difference might be:

1. We will be criticized, as Justin said, for not offering it to other
users. Some normal users have been asking for a slower-updating
version of Firefox, and if we do all the work to actually release such
a thing, but say it isn't for them, there will be resentment.

2. We can't actually prevent normal users from using the ESR version,
installing it for their parents, recommending it to their friends,
etc. It may end up popular among normal users. I do see your point
about FF 3.6, and the lack of interest there despite it being
supported and available. My suspicion though is that FF 3.6 is so
outdated (slow, less aesthetic, etc.) compared to the current releases
that it doesn't have much of a chance anyhow. But the ESR will be
quite close to the normal rapid release version - just less rapidly
updating. We have heard normal users asking for exactly that. So it is
at least possible that if we release it, it will be popular.

I hope I am wrong here.

- azakai

[Asa Dotzler]

Robert Kaiser wrote:
> Kev Needham schrieb:
>> 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.
>
> How many resources should us people working on Mozilla (employees,
> contractors, volunteer helpers) branch off of working on new releases
> and channel into maintaining ESR instead?

As a Mozilla contributor who normally puts primary his efforts into
Firefox, unless you've been explicitly asked to help out, I recommend
you do zero to help with ESR. Your efforts are much more valuable to the
broader Mozilla ecosystem and to the Web.

> In my personal example, I'm watching, analyzing and trying to get fixes
> for crashes in latest Nightly, Aurora, Beta and Release versions, along
> with other tasks like bringing the analysis tools forward, this already
> often maxes out what I can do in my work time. What should I let fall on
> the side to look at ESR as well? Or should I ignore ESR in my daily
> work? Has the Enterprise Working Group thought about those things as well?

You should ignore ESR.

> (I know that in the end it's my decision what I concentrate on, but I'd
> like to hear your proposal of how we should split our attention there.
> The same thing applies to QA, support, security, and other areas, so
> this is not a one-off but a common issue for contributors of any kind.)

As I noted above, the overwhelming majority of Mozilla contributors,
unless they have a particular interest (if they're volunteers) or
specific direction from their employer or management chain (if they're
paid to work on Mozilla) will most likely continue their regular Mozilla
activities as if ESR didn't exist.

- A

[Mike Hommey]

The problem with separating different issues involving the same
sub-problem, being that some kind of long term support is required, is
that doing so would end up with several different overlapping proposals
for basically the same thing, except it wouldn't have the same target.
So here is my question: do you really think it's sane to have three
different long time supported releases ? Obviously, no.

Mike

[Asa Dotzler]

No. I don't think it's sane to have three different longer-term
supported releases. I personally don't think we should have even one
long term supported releases. That being said, if we have to have _one_,
for the potentially tens of millions of users in managed deployment
environments, I think this is about as good a compromise as is possible.

If you're suggesting that we need to have longer-term supported releases
for additional constituencies, I think you should seek support for that
premise (in new threads) before trying to shoehorn additional
requirements into this proposal or trying to use this thread to urge
Mozilla to move away from the new faster release process.

- A

[Henri Sivonen]

On Thu, Sep 22, 2011 at 5:34 PM, Kev Needham <k...@mozilla.com> wrote:
> 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.

If an organization wants to deploy Firefox ESR on Linux, they'll want
it as a .deb or .rpm--just like on Windows they want .msi. Mozilla has
for years failed to provide .rpm or .deb, so I think it's fair to
assume that Mozilla won't be able to start providing .deb and .rpm by
the time the first ESR is going to be released.

I think it's unreasonable from the practical point of view to prohibit
an experienced third party such as Red Hat or Canonical from providing
the service of packaging Firefox ESR as .rpm or .deb. Moreover, if
Mozilla prohibits packaging and calling the package "Firefox ESR" (or
whatever the name will be), I predict we'll get another round of bad
press and lost goodwill as happened when Mozilla didn't let Debian
ship "Firefox". (And we *still* haven't fixed that!)

Even if only a small minority of people wanted to actually run Firefox
ESR, I expect putting a lot of restrictions on who and how gets to
distribute it will be seen as a move that's contrary to software
freedom and will cause bad press and loss of goodwill beyond the
population actually interested in running it. (I believe the mindshare
effects of the Debian situation extended past the people who'd
actually want to run Debian and an outdated Firefox on Debian.)

Moreover, I think the Mission or the way people perceive Firefox
competitively relative to Chrome wouldn't be hurt enough to worry
about if Red Hat shipped Firefox ESR for RHEL Desktop (since RHEL is
enterprise-oriented and isn't used by the general population or
enthusiasts) or if Debian shipped Firefox ESR (since Debian has a
reputation of shipping severely out-of-date software anyway).

I think it would hurt Firefox if Ubuntu and Fedora (both are used by
individual enthusiasts who might run benchmarks and both are expected
to ship relatively fresh software) shipped Firefox ESR by default.
However, I find it encouraging that Chris Coulson over in the other
thread wasn't in favor of putting ESR in Ubuntu by default. Maybe we
don't even need a trademark stick to keep Ubuntu and Fedora shipping
rapid release.

I think not letting Linux distros package ESR would be bad policy and
Mozilla should at least let organizations that have a trademark
license to ship Firefox as part of an operating system to also provide
Firefox ESR as an optional package for the operating system.

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

[Patrick Finch]

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

Amen. Specifically: we will position and differentiate it, we won't
promote it.

Patrick

--
Patrick Finch
Mozilla
pat...@mozilla.com
Mobile: +46 768 444 833
Office: +1 650 903 0800 ext. 340
Twitter: @patrickf
IM: patric...@gmail.com

[Mike Hommey]

At this point, I'm not suggesting anything, I'm barely saying that the
proposal only targets one part of the long term support problem, and
that all the others are completely left out. Again, the different needs
for long term support are intertwined. Deciding on one is effectively
deciding on all of them, since we're not going to have several. But
again, I'm not suggesting anything, the resolution could very well be
that we don't care. But it would have to be said at some point, and not
keep giving our ecosystem false hopes. But okay, I'll start new threads.

> trying to use this
> thread to urge Mozilla to move away from the new faster release
> process.

Where did I say that, exactly?

Mike

[Mad Maks]

Op 09/21/11 23:13, Kev Needham schreef:

> 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

this is now presented as a fact on a dutch website ;
http://www.pcmweb.nl/nieuws/firefox/mozilla-verandert-het-snelle-releaseschema-van-firefox

[David E. Ross]

But is not this ESR proposal a response to complaints about the rapid,
frequent release process? Yes, ESR focuses on resolving those
complaints for enterprise installations. However, as I tried to point
out earlier, those who use applications in an enterprise environment are
individuals who very often use equivalent applications in their personal
environments. Indeed, those who make the decisions regarding what
applications will be deployed in enterprise environments are quite
likely individuals with personal environments. Thus, ESR should not be
restricted to enterprise installations.

[Axel Hecht]

On 22.09.11 15:33, JP Rosevear wrote:
> 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).

I did assume that ESR is string frozen, and that we can have (more or
less) OK builds in languages in question.

I don't think we should offer those just from product arguments:

- profile migration back in time: That may introduce various kinds of
dataloss.
- ESR is not facing users by definition, so we shouldn't offer it
- UX might be degraded (as security to some extent)

Depending on how the missing version relates to the ESR cycle, we don't
win a lot, too.

Axel

[Michael Verdi]

One thing that I haven't seen in the proposal or this discussion is
information about user support expectations. It seems that it may not be
expected by these organizations but I don't know for sure. Regardless,
if enough regular users pick this up (we get many requests for links to
old versions of Firefox today), we'll have to support them. We currently
support two major versions of Firefox, which is difficult with rapid
releases. We were hoping to reap the reward, one day, of only
supporting one. This proposal may mean that we support three different
versions at once. This wouldn't be impossible but it certainly would
come at a cost in terms of both staff and community.

- Michael

[JP Rosevear]

Axel and I discussed this offline. The thought was that if a language
became unsuitable for shipment on a release, we could possibly migrate
people on that language back to the previous ESR.

I believe we both agree this is not a good idea based as per Axel's
earlier assessment.

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

[Christian Legnitto]

I have 2 comments:


ESR and EOL planning
-----------------------------------------

* We need to clearly define what happens to users of a particular ESR version once it is end-of-life, as there will be stragglers

* I suggest when an ESR is end-of-life we move users to the next ESR unconditionally (with a minor / unadvertised update)

* This may get tricky when we drop platforms between ESRs but I think it's better than stranding

* We have experience with this. For Firefox 3.0, if users said no to all major update prompts they stayed on 3.0 indefinitely (or until they manually checked for updates). For 3.5 EOL we instead gave them 3.6 as a minor update (which is why there are fewer 3.0 users than 3.5 right now)


Version to base ESR on?
-----------------------------------------

I don't think we should base it on Firefox 8. Firefox 9 is better than 8 because:

1. Firefox 9 has Type Inference (currently, always a chance of backing out). Because many security fixes are in JS, it seems with a little foresight we can minimize backporting pain. Less manual backporting means less risk to ESR (remember, little to no testers) and less impact on engineering resources

2. If we declare Firefox 8 as ESR, we have 5 weeks to get our ducks in a row. Historically Mozilla has not been good getting out in front and making stuff like this smooth. If we do Firefox 9, we have 11 weeks to get it right (messaging, supporting docs, website changes, engineering repos, figuring out branding, etc)

3. Firefox 8 has the add-on opt-in stuff. We'll be able to see how that plays out in the normal market and perhaps find edge cases that would impact enterprises (as they do a lot of pre-installed / rolled out add-ons). This gives us time to fix up any showstopper issues in Firefox 9

I actually think it makes more sense to base it on Firefox 10 (I know, I know) for the following major reason:

* Firefox 9 is due to ship on 2011-12-20. I highly doubt enterprises would start rolling out until January anyway. If enterprises don't roll out it cuts into the ESR support window and causes additional churn

There are of course a couple of downsides:

1. We need to support 3.6 until then (ugh)

2. The infographic in the proposal states Firefox 8 or 9

If enterprises say that a late December/early January qualification and rollout is actually a good thing this point is moot and we should go with Firefox 9.

Thanks,
Christian

On Sep 28, 2011, at 5:22 AM, JP Rosevear wrote:

> On Sat, 2011-09-24 at 17:11 +0200, Axel Hecht wrote:

> Axel and I discussed this offline. The thought was that if a language
> became unsuitable for shipment on a release, we could possibly migrate
> people on that language back to the previous ESR.
>
> I believe we both agree this is not a good idea based as per Axel's
> earlier assessment.
>
> -JP
> --
> JP Rosevear <j...@mozilla.com>
> Mozilla
>

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

[Jonas Sicking]

On Mon, Oct 3, 2011 at 10:53 AM, Christian Legnitto
<cleg...@mozilla.com> wrote:
> * We have experience with this. For Firefox 3.0, if users said no to all major update prompts they stayed on 3.0 indefinitely (or until they manually checked for updates). For 3.5 EOL we instead gave them 3.6 as a minor update (which is why there are fewer 3.0 users than 3.5 right now)

You mean fewer 3.5 than 3.0 users, right? Since 3.5 users were updated
to 3.6, but 3.0 users were stranded on 3.0.

/ Jonas

[Daniel Veditz]

That's what he meant, and I fact-checked it: there are indeed fewer
3.5 users than 3.0 users.

-Dan Veditz

[Christian Legnitto]

On Oct 3, 2011, at 2:31 PM, Jonas Sicking wrote:

> On Mon, Oct 3, 2011 at 10:53 AM, Christian Legnitto
> <cleg...@mozilla.com> wrote:
>> * We have experience with this. For Firefox 3.0, if users said no to all major update prompts they stayed on 3.0 indefinitely (or until they manually checked for updates). For 3.5 EOL we instead gave them 3.6 as a minor update (which is why there are fewer 3.0 users than 3.5 right now)
>
> You mean fewer 3.5 than 3.0 users, right? Since 3.5 users were updated
> to 3.6, but 3.0 users were stranded on 3.0.

Yep, whoops. Thanks for catching that.

[Alex Limi]

Since people asked for feedback on the ESR plans in general, I'd say that I
am (as is most of the UX team, I believe) still opposed to having a
different release for companies/orgs than for the general population. It
makes support hard, it makes writing add-ons harder, and overall is a
strategy that seems harmful in more ways than it's beneficial.

But if we *are* going to do it, I agree that Firefox 10 (which will
hopefully be the release that makes add-ons compatible by default) should be
the one.

Firefox 9 is scheduled for December 2011, and it seems unlikely that large
organizations are going to do any kind of testing or roll-outs in that time
period anyway. And since 9 has riskier changes than 10 (e.g. Type
Inference), giving it one more release until you lock it down for any
extended amount of time seems prudent.

--
Alex Limi · Firefox UX Team · +limi <http://profiles.google.com/limi> ·
@limi <http://twitter.com/limi/> · limi.net

On Mon, Oct 3, 2011 at 10:53 AM, Christian Legnitto
<cleg...@mozilla.com>wrote:

> I have 2 comments:
>
>
> ESR and EOL planning
> -----------------------------------------
>
> * We need to clearly define what happens to users of a particular ESR
> version once it is end-of-life, as there will be stragglers
>
> * I suggest when an ESR is end-of-life we move users to the next ESR
> unconditionally (with a minor / unadvertised update)
>
> * This may get tricky when we drop platforms between ESRs but I think it's
> better than stranding
>

> * We have experience with this. For Firefox 3.0, if users said no to all
> major update prompts they stayed on 3.0 indefinitely (or until they manually
> checked for updates). For 3.5 EOL we instead gave them 3.6 as a minor update
> (which is why there are fewer 3.0 users than 3.5 right now)
>
>

[Jorge Villalobos]

On 10/3/11 5:43 PM, Alex Limi wrote:
> it makes writing add-ons harder

I don't see how that is really true. Why do you think it would be more
difficult to write add-ons to support Firefox and the ESR?

There would be more work involved if ESR has a different application ID
(which I hope it won't have), but it shouldn't be much more than some
install.rdf and chrome.manifest metadata.

- Jorge

[Jorge Villalobos]

[Boris Zbarsky]

On 10/3/11 7:43 PM, Alex Limi wrote:
> And since 9 has riskier changes than 10

We're all of almost a week into the 10 cycle. Any assumptions about
what changes will be in 10 are somewhat premature.

-Boris

[Asa Dotzler]

Is a different application ID on the table for discouraging consumer
user of ESR? I think that'd be a fine thing.

- A

[Alex Limi]

I was only referring to the chance of FF10 having the "add-ons compatible by
default" approach implemented, whereas 9 does not.

Anything more advanced than that was not my intent. :)

[Alex Limi]

Of course. I based it more on the "I know scary JS stuff landed in 9, but I
haven't seen any scary plans for 10 yet". But yes, we'll see what makes it
in for 10. :)

[Henri Sivonen]

On Tue, Oct 4, 2011 at 2:43 AM, Alex Limi <li...@mozilla.com> wrote:
> Since people asked for feedback on the ESR plans in general, I'd say that I
> am (as is most of the UX team, I believe) still opposed to having a
> different release for companies/orgs than for the general population. It
> makes support hard, it makes writing add-ons harder, and overall is a
> strategy that seems harmful in more ways than it's beneficial.

I think it's bad for the mission to have organizations go back to IE
(the Web moves forward less with IE's EOL cycle) and I think it's bad
for operating system competition if only Windows is perceived to have
an enterprise-friendly browser. Operating system competition is now
more important than ever, because app delivery (including browser
delivery) to operating systems is being locked down.

I think Mozilla should have a product that organizations with large
deployments like. Assuming that the participants in the Enterprise WG
say that ESR would be such a product, I think it makes sense to make
it reality.

[Jorge Villalobos]

A different application ID would discourage *any* use the ESR, given
that it would break *all* add-ons and many enterprises use third-party
add-ons they have no control over.

- Jorge

[Alan Milnes (GP)]

On 4 October 2011 04:34, Asa Dotzler <a...@mozilla.com> wrote:
> Is a different application ID on the table for discouraging consumer user of ESR? I think that'd be a fine thing.

I think it would be an awful thing - only really savvy end users (e.g.
those providing support to friends and family) are going to hunt it
down and use it. Let's not break compatibility just for the sake of
discouraging a tiny minority.

Alan

[Daniel Veditz]

On 9/22/11 6:37 AM, 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?

Depends: is it a Firefox bug or enterprise app bustage due to
collision with a web-spec change that we're not going to back-off
from? If it's a Firefox bug then that two-cycle test period is the
time to report those so we can hopefully get a fix into X.0.2.
Obviously the earlier a bug is reported the sooner we can try to fix
it. If it's a web change then they have that period of time to fix
their web apps.

-Dan Veditz

[Daniel Veditz]

On 10/3/11 8:34 PM, Asa Dotzler wrote:
> Is a different application ID on the table for discouraging consumer
> user of ESR? I think that'd be a fine thing.

You need to chill on the hate for end-users adopting the ESR.
"Slower paced" it may be but it's still a damn sight faster upgrade
path than we've historically had: 42 weeks vs. the current two or
three years for 3.6.x by time it dies (depending on if you count
released life or branch life). And we have to keep on supporting 3.6
the longer the rest of you argue over the ESR plan. Knock it off,
decide, and EOL 3.6 already.

Obviously we're not going to advertise the ESR for users, but taking
active steps to prevent its use really rubs me the wrong way. If
it's a supported release with a clear upgrade path why do we care --
it's the user's browser. So they get half a year behind before being
auto-updated to the next ESR branch. That's nothing in the scheme of
things. If there are compelling features in the cutting edge release
then users will want to use the latest in order to use the cool
sites. If the features aren't compelling that's -our- fault, and it
doesn't really matter if users lag by a little (but still way less
than historically).

We might as well put links to the ESR releases on our site, somewhat
deep like the 3.6 links are today but nonetheless present in a
logical place. If we don't someone else will set up a fan site with
links to the releases anyway, and then we look like jerks for trying
to bury it. We've got metrics on 3.6 downloads, I'm sure we must
know how many come from clicks on the all-older.html page (as
opposed to in-browser upgrades). Is it really so many that it has
you scared?

Thought experiment: pretend Fx4 (March 22) was the first ESR.
Because of the first long cycle Fx5 (June 21) is roughly equivalent
to when we'd EOL the previous hypothetical ESR-0 and upgrade those
folks. ESR-2 would be released with Fx8 (Nov 8), and on January 30,
2012 we'd EOL ESR-1 and upgrade all those folks to ESR-2. That's not
terrible, and we shouldn't freak out if 10-15% of our users wanted
to hang back on a slightly slower paced branch with a good upgrade
story. That's way better than the 30% we've got on the very old 3.6
(plus additional users on older unsupported versions).

-Dan Veditz

[Asa Dotzler]

This conversation isn't delaying ESR or the EOL of 3.6 in any way so
telling me to sit down and shut up so ESR can get moving is kind of bogus.

I am deeply concerned about end users confusion around ESR. You are not.
We disagree.

- A

[Michael Verdi]

Daniel Veditz wrote:
> You need to chill on the hate for end-users adopting the ESR.

Personally, I think this ESR is a bad idea. And from a user support
point of view it could represent a significant cost.

I asked earlier but didn't get an answer about whether enterprise users
will also expect the same kind of user support that we offer all Firefox
users?

Also, if enough regular users pick this up (we get many requests for
links to old versions of Firefox today), we'll have to support the ESR
regardless of enterprise users' expectations. We currently support two
major versions of Firefox, which is difficult enough with rapid
releases. This proposal means that we'll support three different
versions at once (because of the 12 week overlap). This wouldn't be
impossible but it certainly would come at a cost in terms of staff,
community and complexity.

- Michael


--
I work on support
irc: verdi

[Mike Hommey]

3.5 (yes, 3.5, not 3.6) had one release when 4.0 came out, and another
one when 4.0.1 came out. That wouldn't be much different.

Mike

[Chris Hofmann]

On 10/5/11 7:24 AM, Michael Verdi wrote:
> Daniel Veditz wrote:
>> You need to chill on the hate for end-users adopting the ESR.
> Personally, I think this ESR is a bad idea. And from a user support
> point of view it could represent a significant cost.
>
> I asked earlier but didn't get an answer about whether enterprise
> users will also expect the same kind of user support that we offer all
> Firefox users?

Michael, You probably have the answer to that question already. About
20% of "the enterprise" has adopted firefox allready, roughly parrallel
to adoption by individual users.

Do you see significant traffic on SUMO now that you would characterize
as "enterprise support"?

My guess is that adminstrators and help desks within large organizations
pretty much take on the responsibility for helping their users. These
folks may leverage the knowledge base or ask questions in the forums but
those are probably indistinguishable from a question that an individual
user might pose, and in fact they reduce volume on sumo since they are
sharing the information with co-workers.

>
> Also, if enough regular users pick this up (we get many requests for
> links to old versions of Firefox today), we'll have to support the ESR
> regardless of enterprise users' expectations. We currently support two
> major versions of Firefox, which is difficult enough with rapid
> releases. This proposal means that we'll support three different
> versions at once (because of the 12 week overlap). This wouldn't be
> impossible but it certainly would come at a cost in terms of staff,
> community and complexity.
>

Not sure that I follow the math. It should be the same. We are
supporting 3.6.23 now and 7.0. In the future it would be ESR and what
ever the current release is, right?

-chofmann

> - Michael
>
>

[Kev Needham]

A separate AppID is not part of the proposal, and is something that was
stated earlier in this thread. It'd break compatibility with pretty much
any existing addon, and would make the ESR of negligible value for any
organization with users that have addons installed. My proposal is the
opposite, which is to maintain the same AppID and UAString, but maintain
a separate AUS channel.

kev

[Chris AtLee]

On 05/10/11 10:49 AM, Kev Needham wrote:
> A separate AppID is not part of the proposal, and is something that was
> stated earlier in this thread. It'd break compatibility with pretty much
> any existing addon, and would make the ESR of negligible value for any
> organization with users that have addons installed. My proposal is the
> opposite, which is to maintain the same AppID and UAString, but maintain
> a separate AUS channel.
>
> kev

Maintaining a separate AUS channel is going to be tricky for RelEng at
this point. I'd rather distinguish based on version number if possible,
ideally something like 8.0esr, 8.0.1esr for ESR builds based on Firefox 8.

Cheers,
Chris

[Kev Needham]

Hi Michael,

On 11-10-05 10:24 AM, Michael Verdi wrote:
> Personally, I think this ESR is a bad idea.

Any elaboration on this would help. Feel free to DM me if it's
preferred, but I'd like to understand.

And from a user support
> point of view it could represent a significant cost.
>
> I asked earlier but didn't get an answer about whether enterprise users
> will also expect the same kind of user support that we offer all Firefox
> users?

I don't think that's expected, but I will call it out specifically.
End-user support is typically provided by the groups that would be
deploying the ESR. That's also part of why those organizations want a
release that is supported for longer periods, but it's a good point to
reiterate.

> Also, if enough regular users pick this up (we get many requests for
> links to old versions of Firefox today), we'll have to support the ESR
> regardless of enterprise users' expectations. We currently support two
> major versions of Firefox, which is difficult enough with rapid
> releases. This proposal means that we'll support three different
> versions at once (because of the 12 week overlap). This wouldn't be
> impossible but it certainly would come at a cost in terms of staff,
> community and complexity.

I think we can make support options clearer here, as well in our
messaging around the ESR, should we release it. I'd like to understand
what the impact would be if we were up front and said that we're not
going to commit to offering end-user support.

kev

[Kev Needham]

On 11-10-04 10:36 PM, Daniel Veditz wrote:
> On 10/3/11 8:34 PM, Asa Dotzler wrote:
>> Is a different application ID on the table for discouraging consumer
>> user of ESR? I think that'd be a fine thing.
>
> You need to chill on the hate for end-users adopting the ESR.
> "Slower paced" it may be but it's still a damn sight faster upgrade
> path than we've historically had: 42 weeks vs. the current two or
> three years for 3.6.x by time it dies (depending on if you count
> released life or branch life). And we have to keep on supporting 3.6
> the longer the rest of you argue over the ESR plan. Knock it off,
> decide, and EOL 3.6 already.

I don't think Asa's hating, here. He's been up-front about it being a
major concern, and I accept it as a concern, as do a bunch of other
people. How much of it is a concern is something that people's opinions
differ on, but I respect everyone's position, and want to make sure we
as a project are ok with the possible outcomes.

The proposal has been on the table for two weeks, and I want to get to a
decision as quickly as possible. I also want to make very sure that the
decision is an informed one, and welcome any and all constructive
feedback, positive or negative.

I don't plan on sitting on this for an extended period of time, and am
putting together a summation of what I've seen so far in this thread and
elsewhere. Part of that update will be in today's status meeting, but
I'll be posting here as well. It's not any one person's decision, but I
do appreciate the discussion, because it opens my eyes to things I
haven't considered.

I want to kill 3.6 as fast as we possibly can. I want a decision on ESR
as fast as I can get it. That said, I want to do it the right way. I
appreciate everyone for taking the time to share their thoughts, and am
doing my best to incorporate them and push forward.

kev

[Michael Verdi]

Chris Hofmann wrote:
> Not sure that I follow the math. It should be the same. We are
> supporting 3.6.23 now and 7.0. In the future it would be ESR and what
> ever the current release is, right?
>
> -chofmann

I said three because I was counting the people (on 6.x at the moment)
who take a few weeks to update. But you're right, supporting an ESR
would be the same as what we're doing now with 3.6. The point I was
trying (poorly) to make is that supporting both is not ideal and I'd
hoped that it would be a temporary situation. Maintaining two versions
of documents and answering questions about two different versions of
Firefox is difficult. And because it's difficult I think it creates a
barrier for new contributors.

Kev Needham wrote:
> Hi Michael,
>
> On 11-10-05 10:24 AM, Michael Verdi wrote:
>> Personally, I think this ESR is a bad idea.
>
>
> Any elaboration on this would help. Feel free to DM me if it's
> preferred, but I'd like to understand.

I was talking about an ESR in general and not your proposal
specifically. That's not the kind of feedback you asked for - sorry for
the distraction.

>
> And from a user support
>> point of view it could represent a significant cost.
>>
>> I asked earlier but didn't get an answer about whether enterprise users
>> will also expect the same kind of user support that we offer all Firefox
>> users?
>
> I don't think that's expected, but I will call it out specifically.
> End-user support is typically provided by the groups that would be
> deploying the ESR. That's also part of why those organizations want a
> release that is supported for longer periods, but it's a good point to
> reiterate.

If enterprise users aren't expecting the same kind of end user support
as regular firefox users and we can not encourage/discourage/prevent a
significant amount of regular users from adopting it, then my concerns
would be alleviated as sumo will be able to focus our efforts on
supporting the latest version.

>
> I'd like to understand what the impact would be if we were up front
> and said that we're not going to commit to offering end-user support.

I don't know. That sounds kind of like a use-at-your-own-risk kind of
policy which doesn't sound very great. Maybe what's needed is some kind
of support offering for enterprise admins - a way for them to get
questions answered so they can support their users. But if we use no
support as a way to discourage regular users from adopting the ESR it
could come off as somewhat hostile.

- Michael

[Asa Dotzler]

Michael Verdi wrote:
> Daniel Veditz wrote:
>> You need to chill on the hate for end-users adopting the ESR.
> Personally, I think this ESR is a bad idea. And from a user support
> point of view it could represent a significant cost.
>
> I asked earlier but didn't get an answer about whether enterprise users
> will also expect the same kind of user support that we offer all Firefox
> users?

This is one of the reasons why I think it's critical that we keep ESR
out of the hands of audiences which don't have their own support systems
(enterprise users).

> Also, if enough regular users pick this up (we get many requests for
> links to old versions of Firefox today), we'll have to support the ESR
> regardless of enterprise users' expectations. We currently support two
> major versions of Firefox, which is difficult enough with rapid
> releases. This proposal means that we'll support three different
> versions at once (because of the 12 week overlap). This wouldn't be
> impossible but it certainly would come at a cost in terms of staff,
> community and complexity.

Again, we are doing what we can with this proposal to make it clear that
this is for environments that provide their own management and their own
user support. Our Firefox Support community absolutely should not be
expected to support ESR users. If consumers do find the ESR, we should
have a SUMO feature that figures that out and redirects them to a "how
to get on a Mozilla-supported Firefox release".

- A

[Daniel Veditz]

On 10/5/11 8:02 AM, Chris AtLee wrote:
> On 05/10/11 10:49 AM, Kev Needham wrote:
>> My proposal is the opposite, which is to maintain the same
>> AppID and UAString, but maintain a separate AUS channel.
>

> Maintaining a separate AUS channel is going to be tricky for
> RelEng at this point. I'd rather distinguish based on version
> number if possible, ideally something like 8.0esr, 8.0.1esr for
> ESR builds based on Firefox 8.

I don't know if it's possible--currently probably not but there's
rumors of a "channel repack" tool in the works--but it would be
really great if X.0 and X.0esr could be the exact same binary bits
and whatever branding differences happened in-code based on the
channel. That would seem to save us a bunch of build and QA time, at
least on the initial ESR releases when we'd also be dealing with
having to do an update for the previous ESR.

If we could do that we'd only have one really bad release per ESR
cycle where we'd have three simultaneous, different, releases.