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

Showing 1-182 of 182 messages
Proposal to Provide an Extended Support Release of Firefox for Managed Deployments Kev Needham 9/21/11 2:13 PM
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)
Re: Proposal to Provide an Extended Support Release of Firefox for Managed Deployments David E. Ross 9/21/11 2:21 PM
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
Re: Proposal to Provide an Extended Support Release of Firefox for Managed Deployments Justin Scott 9/21/11 2:35 PM
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
Re: Proposal to Provide an Extended Support Release of Firefox for Managed Deployments Kev Needham 9/21/11 2:42 PM
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.

Re: Proposal to Provide an Extended Support Release of Firefox for Managed Deployments L. David Baron 9/21/11 2:54 PM
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/   𝄂
Re: Proposal to Provide an Extended Support Release of Firefox for Managed Deployments Kev Needham 9/21/11 3:16 PM
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.
Re: Proposal to Provide an Extended Support Release of Firefox for Managed Deployments Kyle Huey 9/21/11 3:23 PM
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

Re: Proposal to Provide an Extended Support Release of Firefox for Managed Deployments Jonas Sicking 9/21/11 4:50 PM
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
Re: Proposal to Provide an Extended Support Release of Firefox for Managed Deployments Axel Hecht 9/21/11 5:09 PM
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
Re: Proposal to Provide an Extended Support Release of Firefox for Managed Deployments Jonas Sicking 9/21/11 5:09 PM
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
Re: Proposal to Provide an Extended Support Release of Firefox for Managed Deployments David Mandelin 9/21/11 5:16 PM
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
Re: Proposal to Provide an Extended Support Release of Firefox for Managed Deployments Christian Legnitto 9/21/11 5:16 PM

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
Re: Proposal to Provide an Extended Support Release of Firefox for Managed Deployments Jonas Sicking 9/21/11 5:32 PM
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
Re: Proposal to Provide an Extended Support Release of Firefox for Managed Deployments Cheng Wang 9/21/11 6:45 PM
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?
Re: Proposal to Provide an Extended Support Release of Firefox for Managed Deployments Boris Zbarsky 9/21/11 6:51 PM
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


Re: Proposal to Provide an Extended Support Release of Firefox for Managed Deployments Christian Legnitto 9/21/11 7:19 PM
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
Re: Proposal to Provide an Extended Support Release of Firefox for Managed Deployments Millwood 9/21/11 7:22 PM
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.
Re: Proposal to Provide an Extended Support Release of Firefox for Managed Deployments Cheng Wang 9/21/11 8:08 PM

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

Re: Proposal to Provide an Extended Support Release of Firefox for Managed Deployments azakai 9/21/11 6:16 PM
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
Re: Proposal to Provide an Extended Support Release of Firefox for Managed Deployments Christian Legnitto 9/21/11 8:37 PM


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
Re: Proposal to Provide an Extended Support Release of Firefox for Managed Deployments Justin Lebar 9/21/11 8:58 PM
> 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.
Re: Proposal to Provide an Extended Support Release of Firefox for Managed Deployments Henri Sivonen 9/21/11 11:12 PM
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/
Re: Proposal to Provide an Extended Support Release of Firefox for Managed Deployments Mike Ratcliffe 9/22/11 12:33 AM
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
Re: Proposal to Provide an Extended Support Release of Firefox for Managed Deployments Mike Hommey 9/22/11 12:53 AM
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
Re: Proposal to Provide an Extended Support Release of Firefox for Managed Deployments deep64blue 9/22/11 2:45 AM
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
Re: Proposal to Provide an Extended Support Release of Firefox for Managed Deployments deep64blue 9/22/11 2:49 AM
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
Re: Proposal to Provide an Extended Support Release of Firefox for Managed Deployments deep64blue 9/22/11 3:04 AM
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

Re: Proposal to Provide an Extended Support Release of Firefox for Managed Deployments Mike Hommey 9/22/11 3:16 AM
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
Re: Proposal to Provide an Extended Support Release of Firefox for Managed Deployments Henri Sivonen 9/22/11 3:44 AM
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.)
Re: Proposal to Provide an Extended Support Release of Firefox for Managed Deployments JP Rosevear 9/22/11 6:27 AM
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

Re: Proposal to Provide an Extended Support Release of Firefox for Managed Deployments JP Rosevear 9/22/11 6:33 AM
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).
Re: Proposal to Provide an Extended Support Release of Firefox for Managed Deployments Henri Sivonen 9/22/11 6:37 AM
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?
Re: Proposal to Provide an Extended Support Release of Firefox for Managed Deployments JP Rosevear 9/22/11 6:45 AM
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.

Re: Proposal to Provide an Extended Support Release of Firefox for Managed Deployments Dao 9/22/11 6:58 AM
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.

Re: Proposal to Provide an Extended Support Release of Firefox for Managed Deployments Kev Needham 9/22/11 7:04 AM
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
Re: Proposal to Provide an Extended Support Release of Firefox for Managed Deployments Kev Needham 9/22/11 7:07 AM
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
Re: Proposal to Provide an Extended Support Release of Firefox for Managed Deployments Kev Needham 9/22/11 7:12 AM
That is my proposal, yes.
Re: Proposal to Provide an Extended Support Release of Firefox for Managed Deployments Kev Needham 9/22/11 7:34 AM
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
Re: Proposal to Provide an Extended Support Release of Firefox for Managed Deployments Boris Zbarsky 9/22/11 7:44 AM
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

Re: Proposal to Provide an Extended Support Release of Firefox for Managed Deployments Pascal Chevrel 9/22/11 8:13 AM
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
Re: Proposal to Provide an Extended Support Release of Firefox for Managed Deployments Mike Hommey 9/22/11 8:20 AM
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
>
> _______________________________________________
> dev-planning mailing list
> dev-pl...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-planning

Re: Proposal to Provide an Extended Support Release of Firefox for Managed Deployments WLS 9/22/11 8:49 AM
Firefox Enterprise Edition?

--

SeaMonkey
Re: Proposal to Provide an Extended Support Release of Firefox for Managed Deployments David E. Ross 9/22/11 8:53 AM
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
Re: Proposal to Provide an Extended Support Release of Firefox for Managed Deployments Joshua Cranmer 9/22/11 9:07 AM
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?
Re: Proposal to Provide an Extended Support Release of Firefox for Managed Deployments Johnathan Nightingale 9/22/11 9:25 AM
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

Re: Proposal to Provide an Extended Support Release of Firefox for Managed Deployments Gervase Markham 9/22/11 9:32 AM
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
Re: Proposal to Provide an Extended Support Release of Firefox for Managed Deployments deep64blue 9/22/11 3:26 AM
On 22 September 2011 11:16, Mike Hommey <m...@glandium.org> wrote:

> On Thu, Sep 22, 2011 at 02:49:21AM -0700, deep64blue wrote:
> > 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.
>
> 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
Re: Proposal to Provide an Extended Support Release of Firefox for Managed Deployments Mike Hommey 9/22/11 10:37 AM
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.
Re: Proposal to Provide an Extended Support Release of Firefox for Managed Deployments David E. Ross 9/22/11 10:49 AM
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.

--

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

Re: Proposal to Provide an Extended Support Release of Firefox for Managed Deployments Steve Wendt 9/22/11 10:54 AM
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
Re: Proposal to Provide an Extended Support Release of Firefox for Managed Deployments Christian Legnitto 9/22/11 10:55 AM
This is not a proposal to change the new release process. Please focus on the enterprise proposal and the explicit goals.

Thanks,
Christian
Re: Proposal to Provide an Extended Support Release of Firefox for Managed Deployments Christian Legnitto 9/22/11 10:57 AM
> _______________________________________________
>

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

Thanks,
Christian
Re: Proposal to Provide an Extended Support Release of Firefox for Managed Deployments azakai 9/22/11 11:13 AM
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

Re: Proposal to Provide an Extended Support Release of Firefox for Managed Deployments beltzner 9/22/11 11:46 AM
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

Re: Proposal to Provide an Extended Support Release of Firefox for Managed Deployments Christian Legnitto 9/22/11 12:13 PM
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

Re: Proposal to Provide an Extended Support Release of Firefox for Managed Deployments Asa Dotzler 9/22/11 1:04 PM
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
Re: Proposal to Provide an Extended Support Release of Firefox for Managed Deployments Asa Dotzler 9/22/11 1:06 PM
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
Re: Proposal to Provide an Extended Support Release of Firefox for Managed Deployments Robert Kaiser 9/22/11 2:06 PM
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! :)

Re: Proposal to Provide an Extended Support Release of Firefox for Managed Deployments Robert Kaiser 9/22/11 2:17 PM
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.)
Re: Proposal to Provide an Extended Support Release of Firefox for Managed Deployments Dao 9/22/11 2:22 PM
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.
Re: Proposal to Provide an Extended Support Release of Firefox for Managed Deployments Christian Legnitto 9/22/11 2:23 PM

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
Re: Proposal to Provide an Extended Support Release of Firefox for Managed Deployments azakai 9/22/11 6:24 PM
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

Re: Proposal to Provide an Extended Support Release of Firefox for Managed Deployments Asa Dotzler 9/22/11 8:41 PM
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

Re: Proposal to Provide an Extended Support Release of Firefox for Managed Deployments Mike Hommey 9/22/11 11:08 PM

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

Re: Proposal to Provide an Extended Support Release of Firefox for Managed Deployments Asa Dotzler 9/22/11 11:35 PM

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

Re: Proposal to Provide an Extended Support Release of Firefox for Managed Deployments Henri Sivonen 9/23/11 12:26 AM
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/

Re: Proposal to Provide an Extended Support Release of Firefox for Managed Deployments patrickfinch 9/23/11 12:32 AM

> 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

Re: Proposal to Provide an Extended Support Release of Firefox for Managed Deployments Mike Hommey 9/23/11 12:42 AM

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

Re: Proposal to Provide an Extended Support Release of Firefox for Managed Deployments Mad Maks 9/23/11 5:13 AM
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

Re: Proposal to Provide an Extended Support Release of Firefox for Managed Deployments David E. Ross 9/23/11 8:23 AM

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.

--

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

Re: Proposal to Provide an Extended Support Release of Firefox for Managed Deployments Axel Hecht 9/24/11 8:11 AM
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
Re: Proposal to Provide an Extended Support Release of Firefox for Managed Deployments Michael Verdi 9/27/11 7:43 AM
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
Re: Proposal to Provide an Extended Support Release of Firefox for Managed Deployments JP Rosevear 9/28/11 5:22 AM
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

Re: Proposal to Provide an Extended Support Release of Firefox for Managed Deployments Christian Legnitto 10/3/11 10:53 AM
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
> _______________________________________________
> dev-planning mailing list
> dev-pl...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-planning

Re: Proposal to Provide an Extended Support Release of Firefox for Managed Deployments Jonas Sicking 10/3/11 2:31 PM
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
Re: Proposal to Provide an Extended Support Release of Firefox for Managed Deployments Daniel Veditz 10/3/11 2:50 PM

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

-Dan Veditz

Re: Proposal to Provide an Extended Support Release of Firefox for Managed Deployments Christian Legnitto 10/3/11 3:07 PM

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.
Re: Proposal to Provide an Extended Support Release of Firefox for Managed Deployments Alex Limi 10/3/11 4:43 PM
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)
>
>
Re: Proposal to Provide an Extended Support Release of Firefox for Managed Deployments jorgev 10/3/11 5:11 PM
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
Re: Proposal to Provide an Extended Support Release of Firefox for Managed Deployments jorgev 10/3/11 5:11 PM
Re: Proposal to Provide an Extended Support Release of Firefox for Managed Deployments Boris Zbarsky 10/3/11 5:28 PM
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
Re: Proposal to Provide an Extended Support Release of Firefox for Managed Deployments Asa Dotzler 10/3/11 8:34 PM
Is a different application ID on the table for discouraging consumer
user of ESR? I think that'd be a fine thing.

- A
Re: Proposal to Provide an Extended Support Release of Firefox for Managed Deployments Alex Limi 10/3/11 9:31 PM

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 · Firefox UX Team · +limi <http://profiles.google.com/limi> ·
@limi <http://twitter.com/limi/> · limi.net

Re: Proposal to Provide an Extended Support Release of Firefox for Managed Deployments Alex Limi 10/3/11 9:32 PM
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. :)
Re: Proposal to Provide an Extended Support Release of Firefox for Managed Deployments Henri Sivonen 10/3/11 11:41 PM
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.
Re: Proposal to Provide an Extended Support Release of Firefox for Managed Deployments jorgev 10/4/11 8:36 AM
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
Re: Proposal to Provide an Extended Support Release of Firefox for Managed Deployments deep64blue 10/4/11 8:59 AM
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

Re: Proposal to Provide an Extended Support Release of Firefox for Managed Deployments Daniel Veditz 10/4/11 5:55 PM
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
Re: Proposal to Provide an Extended Support Release of Firefox for Managed Deployments Daniel Veditz 10/4/11 7:36 PM
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
Re: Proposal to Provide an Extended Support Release of Firefox for Managed Deployments Asa Dotzler 10/4/11 7:55 PM
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
Re: Proposal to Provide an Extended Support Release of Firefox for Managed Deployments Michael Verdi 10/5/11 7:24 AM
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

Re: Proposal to Provide an Extended Support Release of Firefox for Managed Deployments Mike Hommey 10/5/11 7:39 AM
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
Re: Proposal to Provide an Extended Support Release of Firefox for Managed Deployments Chris Hofmann 10/5/11 7:49 AM
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
>
>

Re: Proposal to Provide an Extended Support Release of Firefox for Managed Deployments Kev Needham 10/5/11 7:49 AM
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
Re: Proposal to Provide an Extended Support Release of Firefox for Managed Deployments Chris AtLee 10/5/11 8:02 AM
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
Re: Proposal to Provide an Extended Support Release of Firefox for Managed Deployments Kev Needham 10/5/11 8:02 AM
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
Re: Proposal to Provide an Extended Support Release of Firefox for Managed Deployments Kev Needham 10/5/11 8:09 AM
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

Re: Proposal to Provide an Extended Support Release of Firefox for Managed Deployments Michael Verdi 10/5/11 9:30 AM
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


Re: Proposal to Provide an Extended Support Release of Firefox for Managed Deployments Asa Dotzler 10/5/11 11:27 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?


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
Re: Proposal to Provide an Extended Support Release of Firefox for Managed Deployments Daniel Veditz 10/5/11 12:17 PM
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.
Re: Proposal to Provide an Extended Support Release of Firefox for Managed Deployments Ben Hearsum 10/5/11 12:20 PM
On 10/05/11 03:17 PM, Daniel Veditz wrote:
> 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

No development has been started on this, AFAIK.
Re: Proposal to Provide an Extended Support Release of Firefox for Managed Deployments Ben Hearsum 10/5/11 12:20 PM
On 10/05/11 03:17 PM, Daniel Veditz wrote:
> 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
Re: Proposal to Provide an Extended Support Release of Firefox for Managed Deployments Chris AtLee 10/5/11 12:23 PM
> 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.

As you say, this only applies to the first X.0 release (and any
chemspills). We're going to need to build separate builds for X.1esr
since X.1 vanilla won't exist. Having separate build processes for
X.0esr and X.Yesr (Y >= 1) sounds like a bad idea.

Also, we don't currently have the tools to maintain a new ESR specific
update channel, which is why I'd like to distinguish them by the version
number.

Cheers,
Chris
Re: Proposal to Provide an Extended Support Release of Firefox for Managed Deployments Kev Needham 10/5/11 12:37 PM
Would we be able to maintain a sub-channel under release, like we do
with repacks, and just ensure that the process we maintain for updates
prevents fallback from kicking in (e.g. make sure we have
distribution-specific updates on the wire so normal updates don't get
pushed through), or would there be risk there?

k
Re: Proposal to Provide an Extended Support Release of Firefox for Managed Deployments Daniel Veditz 10/5/11 1:36 PM
On 10/5/11 8:09 AM, Kev Needham wrote:
> I don't think Asa's hating, here.

I don't either, it was a disastrous attempt to set a lighthearted
tone through exaggerated use of slang. I apologize for any offense
and derailing the conversation.

-Dan Veditz
Re: Proposal to Provide an Extended Support Release of Firefox for Managed Deployments Kyle Huey 10/5/11 6:37 PM
On Mon, Oct 3, 2011 at 8:28 PM, Boris Zbarsky <bzba...@mit.edu> wrote:

Indeed.  Especially since we're likely to move plugins to content in this
cycle, I wouldn't call this a low risk cycle.

- Kyle
Re: Proposal to Provide an Extended Support Release of Firefox for Managed Deployments David Tenser 10/6/11 8:21 AM
On 2011-10-05 17:02, Kev Needham wrote:
> Hi Michael,
>
> On 11-10-05 10:24 AM, Michael Verdi wrote:
>> 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.
>
> 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.

Assuming that this ESR proposal is accepted, here are some things to
think about for end-user and IT admin support:

First of all, we should distinguish between end-user support (e.g how to
use private browsing, how do I back up my bookmarks) and specific IT
admin support (e.g. best practices for how to deploy Firefox on a large
site).

1. Let's start with end-user support -- this is what we do on SUMO
today. The question that Michael raised was: will users of ESR builds
(i.e. employees at enterprises) expect to have end-user support
available on SUMO? Or do we expect their IT admins to provide that
support locally? And even if they do, maybe these IT admins have relied
on SUMO in the past to solve problems? (We support 3.6 on SUMO today,
which is basically the equivalent of an ESR right now.)

Knowing this will help us decide whether or not we to also support the
latest ESR release on SUMO in the future.

That said, no matter what the answer is for the future, 40% of our
traffic is still coming from 3.6 users today, so it's pretty safe to say
that there is still a need for 3.6 support. As long as this is true, we
should support 3.6 in our Knowledge Base. (In the forum, we already
encourage people to upgrade.)

2) On to IT admin support -- we don't do this on SUMO today, but we
could, depending on what the needs are. In the past, enterprise admins
have been fine with administrating and supporting Firefox on their own
(possibly with the help of our SUMO content for troubleshooting
problems). Also relevant here is that we have an Enterprise Working
Group set up where enterprise admins are already participating in
discussions.

The question is: is there a need for an enterprise-specific section on
SUMO -- e.g. some KB articles about how to deploy Firefox (best
practices, etc) as well as a support forum where admins can help
themselves? This would be fairly straightforward to set up, but it
should obviously be driven by demand.

- David

Re: Proposal to Provide an Extended Support Release of Firefox for Managed Deployments David Tenser 10/6/11 8:25 AM
On 2011-10-06 17:21, David Tenser wrote:
> 1. Let's start with end-user support -- this is what we do on SUMO
> today. The question that Michael raised was: will users of ESR builds
> (i.e. employees at enterprises) expect to have end-user support
> available on SUMO? Or do we expect their IT admins to provide that
> support locally? And even if they do, maybe these IT admins have relied
> on SUMO in the past to solve problems? (We support 3.6 on SUMO today,
> which is basically the equivalent of an ESR right now.)
>
> Knowing this will help us decide whether or not we to also support the
> latest ESR release on SUMO in the future.

I should also point out that it might be possible to implement a
technical solution where supporting the latest ESR basically just means
tagging a specific revision of each KB article and declare that
"revision X of article Y is for the latest Firefox ESR".

That way, we wouldn't have to maintain two versions concurrently in the
each article's wiki syntax, but would instead just serve ESR Firefox
users with an older revision of the support content that was the most
up-to-date revision when the ESR version was the latest normal Firefox
version.

Re: Proposal to Provide an Extended Support Release of Firefox for Managed Deployments David Tenser 10/6/11 9:33 AM
On 2011-10-05 16:49, Chris Hofmann wrote:
> 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.

So that's one thing we don't know for sure yet: do these admins (who
presumably handle their internal support on their own) use SUMO when
troubleshooting problems? If so, in order to maintain the same quality
of support as we offer today on SUMO, we will have to always support the
latest ESR + latest rapid release (RR) at all times. That's essentially
what we do today since we're still supporting 3.6 (representing 40% of
the SUMO traffic at the moment).

But if these admins don't even use SUMO to look up troubleshooting info,
do we really have to keep supporting ESR + RR concurrently?

Also relevant is that at any given time, most of the support content for
Firefox 8 will probably be very similar to the support for Firefox 12 or
so -- in other words, even if we did decide to stop supporting two
versions concurrently on SUMO, for the majority of the cases these
enterprise admins could still use the SUMO content for their internal
troubleshooting.

So, which one is the right call here? Supporting two versions
concurrently adds a lot of complexity to the syntax of each article, and
multiplied with the l10n efforts required, it ends up being a pretty
costly task to maintain them. So obviously, we would all love if
enterprises didn't need any form of end-user type of support from us.

Another option is that we set up a technical solution where support for
the latest ESR basically just means pointing to an older revision of a
KB article. In other words, the support for an old Firefox release is
"archived" somehow, and brought back only for ESR users. That would take
care of maintaining the level of support we offer today with 3.6+latest
RR, while still significantly reducing the work of our l10n community.

- David
Re: Proposal to Provide an Extended Support Release of Firefox for Managed Deployments chris hofmann 10/6/11 9:46 AM
hard to say how you would ever figure that out without more detailed
data on who and why people visit the site.  One idea would be to support
ESR and RR versions for a few months, and then check metrics on usage of
ESR.  If no one is using it shut it down.

Your plan for supporting rapid releases probably also covers any ESR
users since you plan to have the same basic coverage for versions 8-12
with roughly the same content.

Either system would seem to work, although it would allow some addtional
interesting metric about who, why, and how much people use ESR if you
had something set up like option 1.

-chofmann
>
> Also relevant is that at any given time, most of the support content
> for Firefox 8 will probably be very similar to the support for Firefox
> 12 or so -- in other words, even if we did decide to stop supporting
> two versions concurrently on SUMO, for the majority of the cases these
> enterprise admins could still use the SUMO content for their internal
> troubleshooting.
>
> So, which one is the right call here? Supporting two versions
> concurrently adds a lot of complexity to the syntax of each article,
> and multiplied with the l10n efforts required, it ends up being a
> pretty costly task to maintain them. So obviously, we would all love
> if enterprises didn't need any form of end-user type of support from us.
>
> Another option is that we set up a technical solution where support
> for the latest ESR basically just means pointing to an older revision
> of a KB article. In other words, the support for an old Firefox
> release is "archived" somehow, and brought back only for ESR users.
> That would take care of maintaining the level of support we offer
> today with 3.6+latest RR, while still significantly reducing the work
> of our l10n community.
>
> - David
> _______________________________________________
> dev-planning mailing list
> dev-pl...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-planning

Re: Proposal to Provide an Extended Support Release of Firefox for Managed Deployments David Tenser 10/6/11 10:09 AM
On 2011-10-06 18:46, chris hofmann wrote:
> On 10/6/11 9:33 AM, David Tenser wrote:
>> On 2011-10-05 16:49, Chris Hofmann wrote:
>>> 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"?
>>>

We know that 40% of the traffic to SUMO comes from 3.6 users. But how
large part of that is from enterprise admins and users looking for help?
We don't know.

Also, the 40% figure itself might be very skewed since 3.6 binds the F1
key to Support, and Firefox 4 and above does not. So, we're a bit in the
dark at the moment.

I suspect that once the first ESR release ships, there will still be
some 35-40% of the traffic coming from 3.6 users. What do we do with
those at that point? Tell them to upgrade and stop supporting them on
SUMO? (I'd be fine with that, but we should have this discussion first.)

>> But if these admins don't even use SUMO to look up troubleshooting
>> info, do we really have to keep supporting ESR + RR concurrently?
>
> hard to say how you would ever figure that out without more detailed
> data on who and why people visit the site. One idea would be to support
> ESR and RR versions for a few months, and then check metrics on usage of
> ESR. If no one is using it shut it down.

Or, we could simply support the latest RR and ignore the latest ESR and
see how well that plays out. It's not until the latest ESR < latest RR
that we would be able to see if enterprise users' demand rise. And it's
not until then that we'd be able to see how large the traffic is coming
in from the ESR build vs the RR train.

But we need to be aware that this would represent a step back compared
to what enterprise users on 3.6 are getting today, since they can
actually go to SUMO and get full support.

>
> Your plan for supporting rapid releases probably also covers any ESR
> users since you plan to have the same basic coverage for versions 8-12
> with roughly the same content.

Just so I understand what you mean here: you're saying that even if we
supported only the latest RR, most of the content would still apply to
the latest ESR, so most of the support incidents would still be covered?
I think that's reasonable to believe, yeah.

>
> Either system would seem to work, although it would allow some addtional
> interesting metric about who, why, and how much people use ESR if you
> had something set up like option 1.

The thing we have today is webtrends, and I believe we can see exactly
which versions of Firefox our visitors are using. I'm not sure if it
will be able to distinguish an ESR build from a RR build though. Anyone
knows?
Re: Proposal to Provide an Extended Support Release of Firefox for Managed Deployments Chris Hofmann 10/6/11 1:08 PM
On 10/6/11 8:21 AM, David Tenser wrote:
>
>
> The question is: is there a need for an enterprise-specific section on
> SUMO -- e.g. some KB articles about how to deploy Firefox (best
> practices, etc) as well as a support forum where admins can help
> themselves? This would be fairly straightforward to set up, but it
> should obviously be driven by demand.
>
most of what we have for this is on the wiki or devmo.  I think we
should continue with that strategy.

SUMO's mission has been to serve individual users.  To the extent that
it serves users or administrators in larger organizations along the way
it can and should do so.  I really don't think that we need to over
rotate or change a lot round what what SUMO is doing if we do ESR or not
especially in the absence of any specific support requests from people
in large organizations now, or over the history of SUMO.

you said it best.  let any new requests be driven by demand.

-chofmann
unk...@googlegroups.com 10/6/11 1:30 PM <This message has been deleted.>
Re: Proposal to Provide an Extended Support Release of Firefox for Managed Deployments Danny Rushyo Moules 10/6/11 1:27 PM
On Oct 4, 1:11 am, Jorge Villalobos <jo...@mozilla.com> wrote:
> 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

I agree. They're capable of going in and editing the install.rdfs - we
already do this at my workplace. The ESR is made on the assumption
that there are burdens here that enterprises can bear and individuals
cannot.

I honestly feel if individual users start using the ESR we're
basically stuffed. How can we achieve the mission's promise of
security for end users who have no idea how to secure an ESR
deployment?

Enterprises have a different set of circustances. They can make the
ESR work because they have certain constraints, rules and assets that
they choose to enact that individual users do not. They can control
their assets and their networks to fence off ESR appropriately and
minimise risks.

Individial users canno do thst. If they switch to ESR they won't vet
it. They won't secure it. They won't silo it. The implicit contract
with ESR that we seem to be offering is "use at your own risk if you
think you're capable of dealing better with this" - the further
assumption being that these are things _enterprises_ can do.

ESR will offer genuine value to enterprises who can tame it. ESR risks
offering the false perception of value to users who will not properly
analyse or understand these risks and will ultimately come away hugely
disappointed (or hacked). Mozilla cannot hope to educate the entire
web about the reality no matter what we try, so it makes sense to
apply other measures.

How many individuals do you know who risk assess their browser?...
(outside Mozilla anyway)

On 10/3/11 5:43 PM, Alex Limi wrote:
> 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.

Enterprises aren't asking for these things. If they really need an add-
on they can pay a bounty or take it in house. Again, that's what we do
here (and we're only ~1000 people where Fx isn't nearly our primary
browser). By minimising the amount of individual users with these
kinds of expectations, the burden on Firefox is minimised because we
don't have to offer things that customarily come with Firefox.

What I'm getting at is I'm of the opinion that the more strictly ESR
is aimed at enterprises the better it is for Mozilla all around. The
burden shifts on to the enterprises - which seems to be what they
want. Less releases, less interference, less help - essentially.

-Danny
Re: Proposal to Provide an Extended Support Release of Firefox for Managed Deployments Daniel Veditz 10/6/11 7:01 PM
On 10/6/11 10:09 AM, David Tenser wrote:
> We know that 40% of the traffic to SUMO comes from 3.6 users.

That's unfortunate as 3.6 represents 30% of our users (unless you're
lumping all 3.x users together).

> I suspect that once the first ESR release ships, there will still be
> some 35-40% of the traffic coming from 3.6 users. What do we do with
> those at that point? Tell them to upgrade and stop supporting them
> on SUMO? (I'd be fine with that, but we should have this discussion
> first.)

At some point we have to stop supporting 3.6. Hopefully we can drive
those numbers down by prompting upgrades to a newer release with
compelling features.

> The thing we have today is webtrends, and I believe we can see
> exactly which versions of Firefox our visitors are using. I'm not
> sure if it will be able to distinguish an ESR build from a RR build
> though. Anyone knows?

I don't think it was decided. Some people have argued that some
"esr" marker be added to the user agent and others have argued that
it not. Either way, if you see a UA version like 9.0.4 you're
dealing with an ESR build.  "9.0.1" might be ambiguous if there was
a pre-10 chemspill release, but you'd know about that if there were.

-Dan Veditz
Re: Proposal to Provide an Extended Support Release of Firefox for Managed Deployments AndyC 10/7/11 7:52 AM
The thing that instantly jumps out at me, having worked as an
enterprise IT manager in a university for over 10 years, is that a 42
week cycle is exceptionally difficult to plan for over the long term
since it inevitably falls at different points of the year as time
progresses.

Consider, for example, a computer science department that wants
Firefox on their lab computers so that students can do their
coursework in a reliable, standards compliant browser (this was a very
real problem for us until IE9, as the only enterprise friendly browser
was also the least compliant) but they also need to know that they can
rely on consistent behaviour throughout the academic semester. It is
absolutely impossible to consider changing the browser version during
teaching, at any given moment students might be required to
demonstrate a piece of web-development coursework and they cannot be
punished (or use as an excuse) the fact that it was working but some
browser change has now broken their code.

With a 42 week cycle, that isn't something that can be managed. Even
if the changes hit convenient points in the year during year 1, they
will subsequently become more and more difficult to handle during
subsequent years. It leaves IE as the only browser suitable for
deployment, which surely contradicts the Misson? Fixed point in time
changes are so much easier to plan and schedule for, not only in
education environments but across enterprises in general.

I'm not convinced by the attempt to hide the ESR from users either,
there are plenty of examples of more IT-capable providing some degree
of IT support for their families, for example, and they will often
prefer a slower cadence to releases for exactly the same reasons that
enterprises do. They're also probably the people least likely to
require end-user support from mozilla, so I don't really see that as
an issue either. If the genuine belief is that rapid releases are
preferred by end users and offer them significant benefits then there
should be no need at all too dissuade anyone who wants to use the ESR
from doing so. If the argument, however, is that only Mozilla and web-
devs actually want rapid releases and thus there is expected to be a
high take-up of ESR without such dissuasion, then it would be better
to start a wider discussion on why Mozilla is pushing an agenda it's
customers don't want and whether or not that needs rethinking.
Re: Proposal to Provide an Extended Support Release of Firefox for Managed Deployments Mike Hommey 10/7/11 8:14 AM
On Fri, Oct 07, 2011 at 07:52:02AM -0700, AndyC wrote:
> With a 42 week cycle, that isn't something that can be managed. Even
> if the changes hit convenient points in the year during year 1, they
> will subsequently become more and more difficult to handle during
> subsequent years.

In those 42 weeks, you have 12 weeks where 2 ESR versions are supported,
and 12 more weeks during which the next ESR version is in stabilization
phase, and can already be tested and planned.

That's almost 6 months.

Mike
Re: Proposal to Provide an Extended Support Release of Firefox for Managed Deployments andyc...@gmail.com 10/7/11 8:19 AM
It's not that 6 months isn't long enough, it's that those 6 months cover and inconsistent portion of a year. That makes planning and deployment considerably more difficult than it should be.
Re: Proposal to Provide an Extended Support Release of Firefox for Managed Deployments FourthDr 10/7/11 10:06 AM
Why not offer a "Long Term Support" version of firefox based on
3.6.23? I have many add-ons including security add-ons I consider
essential many of which the developers are not able to update at the
same rate as new releases of FF. Also, the new releases contain
"feature" changes which I consider unhelpful and a step backwards from
what 3.6.23 had. Seamonkey is the same way! After at least three or
four updates from v2.2 - 2.4.1 serious problems and adverse UI changes
and bugs have not been fixed! So I am forced to contune to use
Seamonkey 2.0.14 + security fixes/work arounds.



On Sep 21, 2:13 pm, Kev Needham <k...@mozilla.com> 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 athttps://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)

Re: Proposal to Provide an Extended Support Release of Firefox for Managed Deployments Boris Zbarsky 10/7/11 10:33 AM
On 10/7/11 1:06 PM, FourthDr wrote:
> Why not offer a "Long Term Support" version of firefox based on
> 3.6.23?

Most simply because newer releases have security features that are
near-impossible to backport to 3.6.x without significantly rewriting it.

-Boris
Re: Proposal to Provide an Extended Support Release of Firefox for Managed Deployments andyc...@gmail.com 10/7/11 8:19 AM
Re: Proposal to Provide an Extended Support Release of Firefox for Managed Deployments Kev Needham 11/21/11 8:44 AM
Howdy all,

I wanted to let people know that the final draft proposal has been up
for a week or so, and that I'd like to see if there's any final
feedback. I've attempted to clarify/address comments received here,
through the Enterprise Working Group, and direct communications. You can
see the proposal at
https://wiki.mozilla.org/Enterprise/Firefox/ExtendedSupport:Proposal,
and a diff of the current version to the initial proposal at
https://wiki.mozilla.org/index.php?title=Enterprise%2FFirefox%2FExtendedSupport%3AProposal&action=historysubmit&diff=367968&oldid=350369

The changes to the proposal include the following:

- Lengthening the support tail to 9 release cycles (54 weeks), which
would provide a full year coverage to orgs, which was identified as
something which would facilitate release planning and adoption in a
number of orgs
- Basing the initial ESR on Firefox 10.
- Changing the commitment to patch sg:Crits and sg:Highs to something
akin to reasonable efforts, as there may be some changes that cannot be
readily backported
- Clarifying that the Application GUID and versioning will mirror
Firefox's to mitigate addon compatibility pain
- Clarifying locale support
- Clarifying versioning
- Clarifying what happens at the EoL of an ESR release
- Updating included figures to reflect version and support tail changes

If anyone has any further feedback, or if I missed addressing a key
point that you think should have been made from the feedback above,
please let me know. I am hoping to wrap up the process as soon as
possible so a decision can be taken and we can move forward.

Many thanks again for your time and contributions,

kev
Re: Proposal to Provide an Extended Support Release of Firefox for Managed Deployments Mike Hommey 11/21/11 9:37 AM
Hi Kev,
One the concerns from the original proposal, which hasn't changed, is
the following:
"Public (re)distribution of Mozilla-branded versions of the ESR will not
be permitted."

Was it an oversight?

Mike
Re: Proposal to Provide an Extended Support Release of Firefox for Managed Deployments Kev Needham 11/21/11 9:53 AM
Thanks, Mike.

I'll clarify that, as well, in the proposal. The ESR will be subject to
the same terms as any other modified version of Firefox, and will
require authorization from Mozilla to distribute it.

kev

On 11-11-21 12:37 PM, Mike Hommey wrote:
> Hi Kev,
Re: Proposal to Provide an Extended Support Release of Firefox for Managed Deployments deep64blue 11/21/11 9:56 AM
On 21 November 2011 17:37, Mike Hommey <m...@glandium.org> wrote:

> One the concerns from the original proposal, which hasn't changed, is
> the following:
> "Public (re)distribution of Mozilla-branded versions of the ESR will not
> be permitted."
>
> Was it an oversight?
>
>
I agree I don't like that either.

Alan
Re: Proposal to Provide an Extended Support Release of Firefox for Managed Deployments deep64blue 11/21/11 10:09 AM
On 21 November 2011 17:53, Kev Needham <k...@mozilla.com> wrote:

> Thanks, Mike.
>
> I'll clarify that, as well, in the proposal. The ESR will be subject to
> the same terms as any other modified version of Firefox, and will require
> authorization from Mozilla to distribute it.
>

How is "public" defined in this context?

Thanks

Alan
Re: Proposal to Provide an Extended Support Release of Firefox for Managed Deployments Gervase Markham 11/22/11 2:47 AM
On 21/11/11 16:44, Kev Needham wrote:
> If anyone has any further feedback, or if I missed addressing a key
> point that you think should have been made from the feedback above,
> please let me know. I am hoping to wrap up the process as soon as
> possible so a decision can be taken and we can move forward.

Hi Kev,

This looks great :-) I have just one big concern. The document says:

"Public (re)distribution of Mozilla-branded versions of the ESR will not
be permitted."

How do you expect to achieve this? The only way I can see of enforcing
it legally is by saying that "ESR binary releases, unlike standard
Firefox binary releases, are not open source software". Open source
requires the right of redistribution. Current Firefox binaries are made
available under the MPL, which gives people that right.

I think making the ESR non-open-source would be a mistake. I see the
risk of channel conflict, but I think that moving to a non-open-source
distribution model is not the way to solve them. I would hope that as
long as Mozilla doesn't promote the builds on its properties, we aren't
going to see much "leakage" of non-enterprise deployments using the ESR.

Also, if we do ban redistribution, and groups do go out and promote the
ESR in areas we would prefer not to have it promoted, they can just link
to our downloads anyway. So it doesn't actually put that much of a
roadblock in the way. Or they'll do a CentOS on us.

I would propose removing that sentence from the proposal, or replacing
it with "Mozilla will strongly discourage public (re)distribution of
Mozilla-branded versions of the ESR."

You wrote in response to Mike Hommey:
 > I'll clarify that, as well, in the proposal. The ESR will be subject to
 > the same terms as any other modified version of Firefox, and will
 > require authorization from Mozilla to distribute it.

People require authorization from Mozilla to distribute versions _they_
have modified if they still want to call it Firefox. But in this case,
it is not them who is doing the modification! So it's an entirely
different scenario.

People do not require authorization from Mozilla to redistributed
unmodified Desktop Firefox or Mobile Firefox. Will the same be true of
unmodified ESR Firefox?

Gerv
Re: Proposal to Provide an Extended Support Release of Firefox for Managed Deployments Kev Needham 11/22/11 6:10 AM
On 11-11-22 5:47 AM, Gervase Markham wrote:
> This looks great :-) I have just one big concern. The document says:
>
> "Public (re)distribution of Mozilla-branded versions of the ESR will not
> be permitted."

So, first things first. The current phrasing is incorrect, and not
modifying it was an unintended oversight. Mike Hommey did bring this up
early on in the process, and I didn't update the doc to reflect the
concern. For that I apologize. :)

Secondly, I want to make it clear what the intent is behind the proposed
limitation. The ESR is targeted at organizations whose internal policies
require it. There are risks that those organizations assume, and I
wanted to ensure that the choice to use the ESR is explicit and that the
ESR is not marketed or distributed as "Mozilla Firefox".

I tried to make it clear that I am referring to builds that use Mozilla
marks to identify it; the source will be freely available for
redistribution, and individuals and organizations are free to compile
and distribute binaries from that source, but the use of marks is
limited. The ESR is a modified version of the base version of Firefox,
and distribution of modified versions - even if they are generated by us
- requires Mozilla's authorization.

One of the stated goals of the proposal is, as you say, along the lines
of "Mozilla will strongly discourage public (re)distribution of
Mozilla-branded versions of the ESR." The proposal seeks to discourage
the distribution of the ESR to individuals, and the primary intent is to
do what's possible to avoid confusion between Firefox and Firefox ESR.

A good example of what we're trying to accomplish would be with Linux
distributions. If Firefox is offered as a default application, I'd
expect that Mozilla Firefox would be used. The ESR could be offered as
an app that is not installed by default, and would have to be explicitly
chosen.

The proposed limitation is intended to ensure that the ESR is not
marketed as our official release. What probably makes sense is an
addition to the TM policy - should the proposal be accepted - that lays
out how the marks may be used in conjunction with distribution of the
ESR. I don't want to limit availability to the individuals and
organizations that need the ESR, but I do want to do what I can to
mitigate individuals unknowingly installing a product that isn't what we
typically offer.

I'll update the language in the proposal today, as I agree as is it
doesn't adequately capture intent.

kev
Re: Proposal to Provide an Extended Support Release of Firefox for Managed Deployments Simon Paquet 11/22/11 7:37 AM
Kev Needham wrote on 22. Nov 2011:

> Secondly, I want to make it clear what the intent is behind the
> proposed limitation. The ESR is targeted at organizations whose
> internal policies require it. There are risks that those
> organizations assume, and I wanted to ensure that the choice to
> use the ESR is explicit and that the ESR is not marketed or
> distributed as "Mozilla Firefox".

Basically, you can't have it both ways.

You want organizations to use Firefox, who currently don't (or who
will drop Firefox usage), because of the rapid release cycle.

But if you want them to use Firefox, you'll have to name it Firefox
and not market/distribute it as something else.

> A good example of what we're trying to accomplish would be with
> Linux distributions. If Firefox is offered as a default application,
> I'd expect that Mozilla Firefox would be used. The ESR could be
> offered as an app that is not installed by default, and would have
> to be explicitly chosen.

That will piss-off lots of people without having a clear benefit.

I don't think that Ubuntu with their LTS release or Debian Stable
will do what you ask them to do. Instead they will just choose a
different browser or fork, which gets Mozilla nothing.

If people want to use Firefox ESR, then let them. The Mozilla project
is about choice and openness. I'm missing both the openness and the
choice part here.

IMO a Firefox ESR user is still better for Mozilla than say a Chrome,
IE or Safari user, because he still supports our mission instead of
corporate interests.

Cya
Simon

Re: Proposal to Provide an Extended Support Release of Firefox for Managed Deployments Gervase Markham 11/22/11 7:51 AM
On 22/11/11 14:10, Kev Needham wrote:
> So, first things first. The current phrasing is incorrect, and not
> modifying it was an unintended oversight. Mike Hommey did bring this up
> early on in the process, and I didn't update the doc to reflect the
> concern. For that I apologize. :)

No worries :-)

> Secondly, I want to make it clear what the intent is behind the proposed
> limitation. The ESR is targeted at organizations whose internal policies
> require it. There are risks that those organizations assume, and I
> wanted to ensure that the choice to use the ESR is explicit and that the
> ESR is not marketed or distributed as "Mozilla Firefox".

Are you saying "we want to distribute it as Mozilla Firefox but no-one
else can distribute that exact same version"? Or are you making a
distinction between distributing "Mozilla Firefox" and "Mozilla Firefox
ESR", and saying we don't want the ESR distributed as if it's the main
thing?

You can ensure the ESR is not distributed as plain "Mozilla Firefox" by
us not distributing it ourselves as such. Because then, any version
which was so distributed would have to be modified by someone other than
us, and that requires our permission.

> I tried to make it clear that I am referring to builds that use Mozilla
> marks to identify it; the source will be freely available for
> redistribution, and individuals and organizations are free to compile
> and distribute binaries from that source, but the use of marks is
> limited.

Yes and no. The use of marks is limited by trademark law, which
restricts who can use them in trade. However, using them to label goods
which originate from the owner of the mark, in the exact same way the
mark owner uses them, is _not_ restricted by trademark law.

If I buy a Ford and resell it, I don't have to peel the badge off the
front grille. Even if the person who buys it from me is not getting it
from Ford.

> The ESR is a modified version of the base version of Firefox,
> and distribution of modified versions - even if they are generated by us
> - requires Mozilla's authorization.

I think there is a misunderstanding here about our current policies. We
require permission for people to distribute versions labelled 'Firefox'
where that they themselves have modified the code, but we have never
required permission to redistribute verbatim copies of versions of
Firefox that we have created. In fact, the MPL (under which we
distribute binary Firefox) guarantees people that right.

Fennec is a 'modified version of the base version of Firefox', and we
don't require people to get authorization to redistribute that. Or the
Catalan localized version. Or the version for Mac OS X.

> One of the stated goals of the proposal is, as you say, along the lines
> of "Mozilla will strongly discourage public (re)distribution of
> Mozilla-branded versions of the ESR." The proposal seeks to discourage
> the distribution of the ESR to individuals, and the primary intent is to
> do what's possible to avoid confusion between Firefox and Firefox ESR.

I entirely agree with the intent :-)

> A good example of what we're trying to accomplish would be with Linux
> distributions. If Firefox is offered as a default application, I'd
> expect that Mozilla Firefox would be used. The ESR could be offered as
> an app that is not installed by default, and would have to be explicitly
> chosen.

Linux distributions have to modify the software in order to distribute
it (we don't provide .debs or .rpms) and so require our agreement. We
are not discussing that situation; we are discussing the situation where
people are redistributing unmodified ESR binaries downloaded from us.
Your current wording purports to restrict that; I am suggesting that the
only legal way to do that is a route we don't want to go down.

> The proposed limitation is intended to ensure that the ESR is not
> marketed as our official release. What probably makes sense is an
> addition to the TM policy - should the proposal be accepted - that lays
> out how the marks may be used in conjunction with distribution of the
> ESR.

Our TM policy can only restrict what trademark law allows us to
restrict. You can't use trademark law to prevent people redistributing
the unmodified ESR binaries they get from our webserver. You'd have to
use copyright law for that, and that would make the ESR not-open-source.

Let me try and clear this up with a question: is it your intent that the
binaries of the ESR available from mozilla.org are to be made available,
like all current versions of Firefox, Thunderbird, SeaMonkey etc., under
the MPL?

Gerv
Re: Proposal to Provide an Extended Support Release of Firefox for Managed Deployments Kev Needham 11/22/11 8:04 AM
I don't want it any particular way. I am merely trying to accommodate
viewpoints that have been raised by individuals who have provided input
in the process.

I will take up Gerv's proposed edit, and leave it at that.

kev
Re: Proposal to Provide an Extended Support Release of Firefox for Managed Deployments Kev Needham 11/22/11 8:11 AM
On 11-11-22 10:51 AM, Gervase Markham wrote:
> Yes and no. The use of marks is limited by trademark law, which
> restricts who can use them in trade. However, using them to label goods
> which originate from the owner of the mark, in the exact same way the
> mark owner uses them, is _not_ restricted by trademark law.

Right, so ensuring it is called Mozilla Firefox ESR (or whatever the
full name we use) is mostly what I'm angling for.

> If I buy a Ford and resell it, I don't have to peel the badge off the
> front grille. Even if the person who buys it from me is not getting it
> from Ford.

But you can't represent a Ford Fiesta as a Ford Explorer. That's more
the angle I'm going for.

> I think there is a misunderstanding here about our current policies. We
> require permission for people to distribute versions labelled 'Firefox'
> where that they themselves have modified the code, but we have never
> required permission to redistribute verbatim copies of versions of
> Firefox that we have created. In fact, the MPL (under which we
> distribute binary Firefox) guarantees people that right.

All I really wanted to ensure was that the Mozilla Firefox ESR is
represented as such, and differentiated from our regular release of
Mozilla Firefox to avoid confusion. I'll replace the current text with
your proposed edit, and if the proposal is passed, will look at how we
make it clear that the ESR version is marketed as such in implementation.

k
Re: Proposal to Provide an Extended Support Release of Firefox for Managed Deployments Mike Hommey 11/22/11 8:27 AM
On Tue, Nov 22, 2011 at 11:11:19AM -0500, Kev Needham wrote:
> On 11-11-22 10:51 AM, Gervase Markham wrote:
> >Yes and no. The use of marks is limited by trademark law, which
> >restricts who can use them in trade. However, using them to label goods
> >which originate from the owner of the mark, in the exact same way the
> >mark owner uses them, is _not_ restricted by trademark law.
>
> Right, so ensuring it is called Mozilla Firefox ESR (or whatever the
> full name we use) is mostly what I'm angling for.
>
> >If I buy a Ford and resell it, I don't have to peel the badge off the
> >front grille. Even if the person who buys it from me is not getting it
> >from Ford.
>
> But you can't represent a Ford Fiesta as a Ford Explorer. That's
> more the angle I'm going for.

To be fair, it's not a Ford Fiesta vs Ford Explorer thing, but more of a
Ford Fiesta Mark IV vs. Ford Fiesta Mark VI.

Mike
Re: Proposal to Provide an Extended Support Release of Firefox for Managed Deployments Asa Dotzler 11/22/11 8:43 AM
Gervase Markham wrote:

> Let me try and clear this up with a question: is it your intent that the
> binaries of the ESR available from mozilla.org are to be made available,
> like all current versions of Firefox, Thunderbird, SeaMonkey etc., under
> the MPL?
>
> Gerv

Our binaries do not have to be released under the MPL. That's our choice
and not required by the files themselves being MPL. So long as the
source is available, and it will be, we can release the binaries under a
different license, right? If so, that's the easy solution here.

- A
Re: Proposal to Provide an Extended Support Release of Firefox for Managed Deployments Gervase Markham 11/22/11 8:50 AM
On 22/11/11 16:43, Asa Dotzler wrote:
>> Let me try and clear this up with a question: is it your intent that the
>> binaries of the ESR available from mozilla.org are to be made available,
>> like all current versions of Firefox, Thunderbird, SeaMonkey etc., under
>> the MPL?
>
> Our binaries do not have to be released under the MPL. That's our choice
> and not required by the files themselves being MPL. So long as the
> source is available, and it will be, we can release the binaries under a
> different license, right?

You are quite correct.

> If so, that's the easy solution here.

"Easy", as in "Mozilla has moved away from its commitment to open source
software" easy?

This one's even in the manifesto:

"Free and open source software promotes the development of the Internet
as a public resource."

Do we really want to throw that under the bus because we are worried
that some website will say "here, download the Firefox ESR from me, it's
better than the other Firefox"? Even if we do what you suggest, they can
say exactly the same thing and point at our FTP servers instead - unless
we are planning to only send binaries over secure channels to official
registered members of the Mozilla Firefox Enterprise Access Program.

I think there would be strong negative community and wider reaction to
us shipping a proprietary version of Firefox.

Gerv
Re: Proposal to Provide an Extended Support Release of Firefox for Managed Deployments Kev Needham 11/22/11 9:03 AM
So, before we go merrily on along this point, I'd like to point out that
this is an (important) implementation detail that is moot unless we move
forward. I've stated intents, and think the "strongly discourage" covers
that intent. How we do that is in the implementation, and I just want to
make sure we don't lose sight of the fact that we still haven't taken a
decision on the ESR as a whole.

I am hoping that the distribution issue we're drilling down on is an
edge case. I believe there is clear value in the desktop version of
Firefox, especially with the changes being made for addon compatibility
in 10. I also think there are multiple ways we influence and promote
adoption and work with our community to promote the desktop version over
the ESR as the default version of Firefox for individuals, and we'll
have to work on that.

We have several options, but until we actually say "we're going to do an
ESR", continuing to discuss worst-case scenarios beyond "if we do this,
we need to think about this carefully" (which I think has been
accomplished) is probably not the most effective use of time.

Does the phrasing Gerve proposes of "Mozilla will strongly discourage
public (re)distribution of Mozilla-branded versions of the ESR." capture
our intent for the proposal adequately? I think it does, and I also
think how we do that needs to be addressed after we make a call on the
ESR, but I worry we're focusing on implementation details vs. the
proposal right now.

kev
Re: Proposal to Provide an Extended Support Release of Firefox for Managed Deployments Simon Paquet 11/22/11 9:23 AM
Kev Needham wrote on 22. Nov 2011:

> I don't want it any particular way. I am merely trying to accommodate
> viewpoints that have been raised by individuals who have provided input
> in the process.

I didn't want to address you directly. Sorry for that. It was meant
more as a general comment. I really don't understand some people's
fixation on the rapid releases being the perfect solution to
everything.

For some people it isn't and we should obviously respect that.

Cya
Simon

Re: Proposal to Provide an Extended Support Release of Firefox for Managed Deployments Simon Paquet 11/22/11 9:27 AM
Asa Dotzler wrote on 22. Nov 2011:

>> Let me try and clear this up with a question: is it your intent that
>> the binaries of the ESR available from mozilla.org are to be made
>> available, like all current versions of Firefox, Thunderbird, SeaMonkey
>> etc., under the MPL?
>
> Our binaries do not have to be released under the MPL. That's our choice
> and not required by the files themselves being MPL. So long as the
> source is available, and it will be, we can release the binaries under a
> different license, right? If so, that's the easy solution here.

Did Netscape die so long ago, that we are now intent on repeating its
mistakes. Or are we just intentionally trying to piss off as many people
in the OSS world as we can be, which is exactly what you are proposing?

Just asking...


--
Simon
Re: Proposal to Provide an Extended Support Release of Firefox for Managed Deployments Gervase Markham 11/22/11 9:45 AM
 22/11/11 17:03, Kev Needham wrote:
> So, before we go merrily on along this point, I'd like to point out that
> this is an (important) implementation detail that is moot unless we move
> forward.

I'm sorry if this discussion is distracting. Yes, let's do the ESR :-)

> Does the phrasing Gerve proposes of "Mozilla will strongly discourage
> public (re)distribution of Mozilla-branded versions of the ESR." capture
> our intent for the proposal adequately? I think it does, and I also
> think how we do that needs to be addressed after we make a call on the
> ESR, but I worry we're focusing on implementation details vs. the
> proposal right now.

I'm (obviously) very happy with that wording.

Gerv

Re: Proposal to Provide an Extended Support Release of Firefox for Managed Deployments deep64blue 11/22/11 9:55 AM
On 22 November 2011 17:03, Kev Needham <k...@mozilla.com> wrote:

> So, before we go merrily on along this point, I'd like to point out that
> this is an (important) implementation detail that is moot unless we move
> forward. I've stated intents, and think the "strongly discourage" covers
> that intent. How we do that is in the implementation, and I just want to
> make sure we don't lose sight of the fact that we still haven't taken a
> decision on the ESR as a whole.
>


> .......
>


> Does the phrasing Gerve proposes of "Mozilla will strongly discourage
> public (re)distribution of Mozilla-branded versions of the ESR." capture
> our intent for the proposal adequately?
>

Yes we should do ESR and yes this wording is fine.

Thanks

Alan
Re: Proposal to Provide an Extended Support Release of Firefox for Managed Deployments Nicholas Nethercote 11/22/11 3:05 PM
On Tue, Nov 22, 2011 at 9:55 AM, Alan Milnes (GP) <al...@gameplan.org.uk> wrote:
>
> Yes we should do ESR

I agree, but I think plenty of people that aren't part of the intended
audience will use the ESR -- i.e. non-org users who don't like rapid
updates.  There are plenty of people who have stuck with 3.6 because
they don't like rapid updates.

Strongly encouraging people to use the non-ESR versions is fine.
Making the download point non-obvious is fine.  But IMHO using legal
barriers to prevent people using or distributing the unmodified ESR is
a terrible idea.

Nick
Re: Proposal to Provide an Extended Support Release of Firefox for Managed Deployments deep64blue 11/22/11 3:08 PM
On 22 November 2011 23:05, Nicholas Nethercote <n.neth...@gmail.com>wrote:
Agree totally.

Alan
Re: Proposal to Provide an Extended Support Release of Firefox for Managed Deployments Christian Legnitto 11/22/11 3:25 PM

On Nov 22, 2011, at 3:05 PM, Nicholas Nethercote wrote:

> On Tue, Nov 22, 2011 at 9:55 AM, Alan Milnes (GP) <al...@gameplan.org.uk> wrote:
>>
>> Yes we should do ESR
>
> I agree, but I think plenty of people that aren't part of the intended
> audience will use the ESR -- i.e. non-org users who don't like rapid
> updates.  There are plenty of people who have stuck with 3.6 because
> they don't like rapid updates.

Show me the data (other than the enterprises we are explicitly targeting with the ESR--that's why the proposal exists). This has somehow been accepted as some higher truth when there isn't really data to back up this assertion (and indeed, we have some data that seems to refute it...even when using nebulous terms like "plenty").

I'm tired of hearing this "truism" bandied about with no supporting evidence and would be happy to see evidence backing it up.

Thanks,
Christian
Re: Proposal to Provide an Extended Support Release of Firefox for Managed Deployments Nicholas Nethercote 11/22/11 3:30 PM
On Tue, Nov 22, 2011 at 3:25 PM, Christian Legnitto
<cleg...@mozilla.com> wrote:
>
>
> Show me the data (other than the enterprises we are explicitly targeting with the ESR--that's why the proposal exists). This has somehow been accepted as some higher truth when there isn't really data to back up this assertion (and indeed, we have some data that seems to refute it...even when using nebulous terms like "plenty").
>
> I'm tired of hearing this "truism" bandied about with no supporting evidence and would be happy to see evidence backing it up.

I have no hard data, just many anecdotes from reading comments on tech
sites.  So feel free to discount that, because the quality-of-data
issue is beside the point.  Even if there's only one non-enterprise
person in the whole world who wants to use the ESR, legal barriers
shouldn't be put in their way.

Nick
Re: Proposal to Provide an Extended Support Release of Firefox for Managed Deployments Christian Legnitto 11/22/11 3:40 PM
FWIW I agree. I also think this will be a non-issue--the number of non-enterprise users opting into ESR will likely be < 500,000, mainly due to not putting a link on mozilla.org. For context, we have over a million people on Firefox 2 still.

That being said, we wanted it explicitly clear in the proposal what our intentions are and if our intuitions are incorrect we don't want to blindside people when we use various tools available to us. If we should use those tools is another matter entirely and we we can have that discussion if the need arises.

Thanks,
Christian

Re: Proposal to Provide an Extended Support Release of Firefox for Managed Deployments azakai 11/22/11 3:52 PM
On Nov 22, 3:05 pm, Nicholas Nethercote <n.netherc...@gmail.com>
wrote:
> On Tue, Nov 22, 2011 at 9:55 AM, Alan Milnes (GP) <a...@gameplan.org.uk> wrote:
>
>
>
> > Yes we should doESR
>
> I agree, but I think plenty of people that aren't part of the intended
> audience will use theESR-- i.e. non-org users who don't like rapid
> updates.  There are plenty of people who have stuck with 3.6 because
> they don't like rapid updates.
>
> Strongly encouraging people to use the non-ESRversions is fine.
> Making the download point non-obvious is fine.  But IMHO using legal
> barriers to prevent people using or distributing the unmodifiedESRis
> a terrible idea.
>
> Nick

I strongly agree. Using legal means to prevent redistribution feels
very wrong for us to do. Not promoting it or recommending people use
another version sounds fine to me.

- azakai
Re: Proposal to Provide an Extended Support Release of Firefox for Managed Deployments Nicholas Nethercote 11/22/11 4:08 PM
On Tue, Nov 22, 2011 at 3:40 PM, Christian Legnitto
<cleg...@mozilla.com> wrote:
>
> the number of non-enterprise users opting into ESR will likely be < 500,000, mainly due to not putting a link on mozilla.org. For context, we have over a million people on Firefox 2 still.

How did you arrive at the estimate of < 500,000?

Nick
Re: Proposal to Provide an Extended Support Release of Firefox for Managed Deployments Christian Legnitto 11/22/11 4:51 PM
It was a mistake to throw out a concrete number without data (whoooo, right after my rant, sorry!). My point is this:

I expect the number of non-enterprise users opting into the ESR to be less than users on <= Firefox 2. This is my *personal* opinion based on the mechanics of releases, various ADU counts and shifts, etc. Because we don't consider those users and the volume as a going concern, I don't anticipate the amount of non-enterprise users opting into the ESR of material significance. I am sure there will be some, definitely.

What we are codifying in the proposal is our desire to have the non-enterprise ESR user number be as low as possible, that is all. FWIW I am not sure about the best way to get there, but I expect us to generally be there with the current mitigation steps.

Of course, we can't really test until we go through it, but the data we have today (# of ADUs on 3.6, divergence between ADU ping and blocklist ping, # of people staying on 4/5/6/7 etc) shows this doesn't look like a concern *now*. I don't see how this will become a concern in the future--users are not opting into 3.6, which acts like an ESR, in any substantial way. Of course, this may change a bit once there is a "modern" ESR, but I think it's best to set expectations, measure, and adjust as necessary.

Thanks,
Christian

Re: Proposal to Provide an Extended Support Release of Firefox for Managed Deployments Asa Dotzler 11/22/11 7:09 PM
Nicholas Nethercote wrote:
> On Tue, Nov 22, 2011 at 9:55 AM, Alan Milnes (GP)<al...@gameplan.org.uk>  wrote:
>> Yes we should do ESR
>
> I agree, but I think plenty of people that aren't part of the intended
> audience will use the ESR -- i.e. non-org users who don't like rapid
> updates.  There are plenty of people who have stuck with 3.6 because
> they don't like rapid updates.

I don't think that's why most people are still on 3.6.  People on 3.6
moved pretty quickly forward when we asked them to. We stopped asking
them the better part of a year ago. We'll ask them again in a couple of
weeks and I expect the bulk of the remaining 3.6 folks to move forward
once we return to prompting them semi-regularly.

- A
Re: Proposal to Provide an Extended Support Release of Firefox for Managed Deployments Henri Sivonen 11/22/11 11:11 PM
On Wed, Nov 23, 2011 at 1:40 AM, Christian Legnitto
<cleg...@mozilla.com> wrote:
> On Nov 22, 2011, at 3:30 PM, Nicholas Nethercote wrote:
>> Even if there's only one non-enterprise
>> person in the whole world who wants to use the ESR, legal barriers
>> shouldn't be put in their way.
>
> FWIW I agree.

I'm very happy to see what looks like a consensus emerging on the
point of allowing redistribution of Mozilla-compiled ESR binaries.

Is the plan to allow third parties who are now licensed to distribute
the mainline Firefox compiled by them also distribute ESR compiled by
them as an option to their users?

I continue to be of the opinion that Mozilla should allow the
packaging of distro-compiled ESR in cases where distros already have a
trademark license to package distro-compiled normal Firefox if there's
an understanding that the normal Firefox remains the package offered
by default. ESR should be required to be identified as ESR in UI
though for technical reasons the .rpm or .deb package name might need
to be just "firefox" in order to work as a drop-in replacement for
normal "firefox" package in dependency chains. I think Mozilla should
also allow a third party to provide an .msi packaging service to
enterprises.

--
Henri Sivonen
hsiv...@iki.fi
http://hsivonen.iki.fi/
Re: Proposal to Provide an Extended Support Release of Firefox for Managed Deployments Bob Chao 11/22/11 11:32 PM
I heard people keep their 3.6 because of their old extension, don't like
the new looking, "feel" that the old version is more stable, or simply
don't know that the new version exist. Rapid updates might not be the main
reason, at least for people I knew.

But what's the problem if non-org people use the ESR version? They should
be able to do so if they do really want and really sure what they are
doing, IMO.

--
Po-chiang Chao  (:BobChao)
Volunteer, MozTW (Mozilla Taiwan Community)
http://moztw.org
Re: Proposal to Provide an Extended Support Release of Firefox for Managed Deployments Boris Zbarsky 11/23/11 5:25 AM
On 11/23/11 2:32 AM, Bob Chao wrote:
> But what's the problem if non-org people use the ESR version? They should
> be able to do so if they do really want and really sure what they are
> doing, IMO.

That "really sure" part is key: we don't want people widely distributing
the ESR builds to a general audience because then people will get
confused between the ESR and actual Firefox and _won't_ be really sure
what they're doing.

-Boris

Re: Proposal to Provide an Extended Support Release of Firefox for Managed Deployments Boris Zbarsky 11/23/11 5:26 AM
On 11/22/11 10:09 PM, Asa Dotzler wrote:
> We'll ask them again in a couple of weeks

For what it's worth, I've been hearing that since July or so...  I'd
really love to see it actually happen, but have to admit I'm losing
faith it will.  :(

-Boris
Re: Proposal to Provide an Extended Support Release of Firefox for Managed Deployments Gervase Markham 11/23/11 6:57 AM
On 22/11/11 23:05, Nicholas Nethercote wrote:
> Strongly encouraging people to use the non-ESR versions is fine.
> Making the download point non-obvious is fine.  But IMHO using legal
> barriers to prevent people using or distributing the unmodified ESR is
> a terrible idea.

I think this point has now been made and understood :-)

Gerv
Re: Proposal to Provide an Extended Support Release of Firefox for Managed Deployments Asa Dotzler 11/23/11 8:06 AM
Yeah. We wanted to do it at 6 but decided to wait until the memory
improvements in 7. Then we had a 7 follow-up that pushed it out to 8.
Then we had the 8 chemspill that pushed it out again but we're not gonna
wait until 9 this time unless the 8.0.1 doesn't work for some reason.
We'll know in another 5 or 6 days.

- A
Re: Proposal to Provide an Extended Support Release of Firefox for Managed Deployments Boris Zbarsky 11/23/11 8:15 AM
On 11/23/11 11:06 AM, Asa Dotzler wrote:
> Then we had a 7 follow-up that pushed it out to 8.

I have to ask: why?  What prevented us from just offering an update from
3.6 to 7.0.1?  Was it something technical on our side, or a
user-perception issue?

-Boris
Re: Proposal to Provide an Extended Support Release of Firefox for Managed Deployments Asa Dotzler 11/23/11 8:27 AM
Resources, I believe. We're trying. Christian could say more.
Re: Proposal to Provide an Extended Support Release of Firefox for Managed Deployments Robert Kaiser 11/23/11 8:36 AM
Bob Chao schrieb:
> But what's the problem if non-org people use the ESR version?

The problem is that they need to be clear that we're not really actively
supporting them. From all I know (and I'm not involved with the
"Enterprise Working Group" at all, so take this with a grain of salt),
we are supporting organization admins who get ESR deployed, but we are
not supporting users of this variant directly.

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 should think about. And most of the
time, I even appreciate irony and fun! :)
Re: Proposal to Provide an Extended Support Release of Firefox for Managed Deployments Chris Hofmann 11/23/11 8:59 AM
On 11/23/11 8:36 AM, Robert Kaiser wrote:
> Bob Chao schrieb:
>> But what's the problem if non-org people use the ESR version?
>
> The problem is that they need to be clear that we're not really
> actively supporting them. From all I know (and I'm not involved with
> the "Enterprise Working Group" at all, so take this with a grain of
> salt), we are supporting organization admins who get ESR deployed, but
> we are not supporting users of this variant directly.
>
> Robert Kaiser
I don't think this is correct. "not really actively supporting them"
doesn't have anything to do with it and is incorrect, since security
patches and update releases will be produced.

At the recent mozcamp's we held sessions to talk about the release
process and get feedback.

In those sessions we outlined the goal that was first and foremost in
changing the release process and that goal centered around the idea
that  2 years, 1.5 years, or even 1 year was to long to go between
updates that contained innovations and improvements that will move the
web forward.   In my mind that applies to individuals and large
organizations.

We want to move faster and find ways to help other move faster as well.  
Many people using the ESR version holds us back from achieving this
goal.   It is my personal hope that ESR is a temporary solution that
will help organizations until they can revise and improve their systems
for certifying and integrating browser updates, and they will soon be on
a path toward adopting new technology at a faster pace.   Many of the
most competitive large organizations are on this path and keeping up
with the faster rapid release cycle.  The remaining organizations should
strive to do better, and use ESR as a temporary solution to get there.

-chofmann
Re: Proposal to Provide an Extended Support Release of Firefox for Managed Deployments Lawrence Mandel 11/23/11 10:11 AM
> We want to move faster and find ways to help other move faster as
> well.
> Many people using the ESR version holds us back from achieving this
> goal. It is my personal hope that ESR is a temporary solution that
> will help organizations until they can revise and improve their
> systems
> for certifying and integrating browser updates, and they will soon be
> on
> a path toward adopting new technology at a faster pace. Many of the
> most competitive large organizations are on this path and keeping up
> with the faster rapid release cycle. The remaining organizations
> should
> strive to do better, and use ESR as a temporary solution to get there.

If we really want to encourage organizations to change their process and get on the rapid release cycle, should the ESR proposal include a program duration/end date? For example,

ESR releases will be created and maintained for X years after which time Mozilla will no longer distribute ESR releases. It is expected that this time period is sufficient for organizations to adapt their existing compliance processes to a more frequent Firefox release cycle.

Lawrence
Re: Proposal to Provide an Extended Support Release of Firefox for Managed Deployments deep64blue 11/23/11 10:19 AM
On 23 November 2011 16:59, Chris Hofmann <chof...@mozilla.com> wrote:

> We want to move faster and find ways to help other move faster as well.
>  Many people using the ESR version holds us back from achieving this goal.
>   It is my personal hope that ESR is a temporary solution that will help
> organizations until they can revise and improve their systems for
> certifying and integrating browser updates, and they will soon be on a path
> toward adopting new technology at a faster pace.   Many of the most
> competitive large organizations are on this path and keeping up with the
> faster rapid release cycle.  The remaining organizations should strive to
> do better, and use ESR as a temporary solution to get there.
>

This could be a whole new debate suffice to say "strive to do better" is
not a phrase I would agree with. Mozilla may think Rapid Release is the way
to go but in many industries and companies it's not - for many
organisations care, precision and reliability are more important than the
latest whizz bang idea.

Alan
Re: Proposal to Provide an Extended Support Release of Firefox for Managed Deployments Chris Hofmann 11/23/11 10:20 AM
On 11/23/11 10:11 AM, Lawrence Mandel wrote:
>> We want to move faster and find ways to help other move faster as
>> well.
>> Many people using the ESR version holds us back from achieving this
>> goal. It is my personal hope that ESR is a temporary solution that
>> will help organizations until they can revise and improve their
>> systems
>> for certifying and integrating browser updates, and they will soon be
>> on
>> a path toward adopting new technology at a faster pace. Many of the
>> most competitive large organizations are on this path and keeping up
>> with the faster rapid release cycle. The remaining organizations
>> should
>> strive to do better, and use ESR as a temporary solution to get there.
> If we really want to encourage organizations to change their process and get on the rapid release cycle, should the ESR proposal include a program duration/end date? For example,
>
> ESR releases will be created and maintained for X years after which time Mozilla will no longer distribute ESR releases. It is expected that this time period is sufficient for organizations to adapt their existing compliance processes to a more frequent Firefox release cycle.
>
> Lawrence

I'd suggest that we just get it up and running, then look at if it is
effective and useful.  But also we are looking at feedback and changes
needed to the rapid release cycle as well.  After both those things are
done, I would think it would be a good time to evaluate how long the
program might be needed or supported.   Anything before those things
happen might be premature.

-chofmann
Re: Proposal to Provide an Extended Support Release of Firefox for Managed Deployments Asa Dotzler 11/23/11 10:22 AM
Yes, this was in the original draft, I haven't checked back in but the
time commitment is not open ended.

- A
Re: Proposal to Provide an Extended Support Release of Firefox for Managed Deployments Chris Hofmann 11/23/11 10:29 AM
On 11/23/11 10:19 AM, Alan Milnes (GP) wrote:
> On 23 November 2011 16:59, Chris Hofmann<chof...@mozilla.com>  wrote:
>
>> We want to move faster and find ways to help other move faster as well.
>>   Many people using the ESR version holds us back from achieving this goal.
>>    It is my personal hope that ESR is a temporary solution that will help
>> organizations until they can revise and improve their systems for
>> certifying and integrating browser updates, and they will soon be on a path
>> toward adopting new technology at a faster pace.   Many of the most
>> competitive large organizations are on this path and keeping up with the
>> faster rapid release cycle.  The remaining organizations should strive to
>> do better, and use ESR as a temporary solution to get there.
>>
> This could be a whole new debate suffice to say "strive to do better" is
> not a phrase I would agree with. Mozilla may think Rapid Release is the way
> to go but in many industries and companies it's not - for many
> organisations care, precision and reliability are more important than the
> latest whizz bang idea.
>
> Alan
>
Those are a couple a pretty broad statements.  First it assumes that
the mozilla project is not striving for precision, reliability and high
quality.

Second it assumes that large organizations should not, can not, or do
not want
to move faster.

On the first point I can tell you that Mozilla is, and all ways will be,
striving
for higher quality.   I don't know what to say about the second point,
but I
do see a lot of large organizations that do want to move faster to stay
competitive in their industry.

I certainly don't want to be the one to kick off another round of debate
so I suggest we end this discussion here.  Anyone interested in continuing
the discussion could e-mail me privately and I could summarize any
important points, and report back.

-chofmann


Re: Proposal to Provide an Extended Support Release of Firefox for Managed Deployments Robert Kaiser 11/23/11 10:30 AM
Chris Hofmann schrieb:
> I don't think this is correct. "not really actively supporting them"
> doesn't have anything to do with it and is incorrect, since security
> patches and update releases will be produced.

Sure, what I meant with "real active support" is that we are directly
doing end-user support in the way we are doing for the most-current
"normal" release. But then, as I said, I'm not actively involved there
and that was my personal impression as someone only reading this thread
and the proposal.
Re: Proposal to Provide an Extended Support Release of Firefox for Managed Deployments Christian Legnitto 11/23/11 10:30 AM
"The initial proposal would be to support a minimum of two ESR releases"

I think that's a good time to figure out what adjustments would need to be made or if the ESR is relevant at all at that point. Who knows what the various constraints and landscape will look like in the (proposed) 2 years time...

Thanks,
Christian

Re: Proposal to Provide an Extended Support Release of Firefox for Managed Deployments Lawrence Mandel 11/23/11 10:36 AM
> >> ESR releases will be created and maintained for X years after which
> >> time Mozilla will no longer distribute ESR releases. It is expected
> >> that this time period is sufficient for organizations to adapt
> >> their existing compliance processes to a more frequent Firefox
> >> release cycle.
> >>
> >> Lawrence
> >
> >
> > Yes, this was in the original draft, I haven't checked back in but
> > the time commitment is not open ended.
>
> "The initial proposal would be to support a minimum of two ESR
> releases"
>
> I think that's a good time to figure out what adjustments would need
> to be made or if the ESR is relevant at all at that point. Who knows
> what the various constraints and landscape will look like in the
> (proposed) 2 years time...
>
> Thanks,
> Christian

Yup. I had missed that statement. Thanks for highlighting it.

Lawrence
Re: Proposal to Provide an Extended Support Release of Firefox for Managed Deployments PhillipJones 11/23/11 4:08 PM
Chris Hofmann wrote:
------------------snip------------------
> Those are a couple a pretty broad statements. First it assumes that
> the mozilla project is not striving for precision, reliability and
> high quality.
 >
> Second it assumes that large organizations should not, can not, or do
> not want to move faster.

Whether the should or should not is questionable
Can not definitely
want to: they would love to.

But when you have big lumbering companies spread all over the US and
world and each has it own IT departments for each division or Office in
many countries can not becomes the issue.

The little mom and pop outfits with 2-20 employees are not the issue.
The companies with 20-20,000 employees or more its is down right
impossible to update on Fast Track.

But what difference does it make. After all the top Brass at Mozilla has
written off Corporate as unimportant, unneeded, or unwanted.

> On the first point I can tell you that Mozilla is, and all ways will
> be, striving for higher quality. I don't know what to say about the
> second point, but I do see a lot of large organizations that do want
> to move faster to stay competitive in their industry.

wanting to and the ability to do so is a different.

> I certainly don't want to be the one to kick off another round of
> debate so I suggest we end this discussion here. Anyone interested in
> continuing the discussion could e-mail me privately and I could
> summarize any important points, and report back.

There is no points in arguing the issue the Mozilla gods have spoken

> -chofmann
>
>


--
Phillip M. Jones, C.E.T.        "If it's Fixed, Don't Break it"
http://www.phillipmjones.net        mailto:pjo...@kimbanet.com
Re: Proposal to Provide an Extended Support Release of Firefox for Managed Deployments Nicholas Nethercote 11/23/11 6:02 PM
On Wed, Nov 23, 2011 at 4:08 PM, PhillipJones <pjo...@kimbanet.com> wrote:
>
> But what difference does it make. After all the top Brass at Mozilla has
> written off Corporate as unimportant, unneeded, or unwanted.

Quit your trolling.  This whole thread and proposal is aimed exactly
at assuaging the complaints from corporate/enterprise users.

Nick
Re: Proposal to Provide an Extended Support Release of Firefox for Managed Deployments Asa Dotzler 11/23/11 7:23 PM
Phillip M. Jones, C.E.T, has been trolling successfully in these groups
for the better part of a decade.

- A
Re: Proposal to Provide an Extended Support Release of Firefox for Managed Deployments Henri Sivonen 11/23/11 11:00 PM
On Wed, Nov 23, 2011 at 8:30 PM, Robert Kaiser <ka...@kairo.at> wrote:
> Sure, what I meant with "real active support" is that we are directly doing
> end-user support in the way we are doing for the most-current "normal"
> release.

Considering how many end users never contact Mozilla for support, I
think it wouldn't be reasonable to tell them they can't have ESR
because they can't contact support staff about it. (I think it would
be reasonable to inform would-be ESR users that ESR comes with a
lesser possibility to contact support staff, though.)
Re: Proposal to Provide an Extended Support Release of Firefox for Managed Deployments Henri Sivonen 11/23/11 11:21 PM
On Thu, Nov 24, 2011 at 9:00 AM, Henri Sivonen <hsiv...@iki.fi> wrote:
> Considering how many end users never contact Mozilla for support, I
> think it wouldn't be reasonable to tell them they can't have ESR
> because they can't contact support staff about it. (I think it would
> be reasonable to inform would-be ESR users that ESR comes with a
> lesser possibility to contact support staff, though.)

Oh, and if ESR is going to get less support, it probably shouldn't be
named *Extended* *Support* Release. :-)

I realize that naming is a total bikeshed, but Long Patch Cycle would
be a more accurate name that also wouldn't imply that enterprises
*have to* prefer it (like calling it Enterprise Edition might do).
Re: Proposal to Provide an Extended Support Release of Firefox for Managed Deployments Michael Lefevre 11/24/11 2:50 AM
As far as I'm aware, users running the latest release don't have any
guaranteed way of "contacting support staff" anyway.  There is, of
course, SUMO, but, good as it is, that is mostly provided by volunteers
- a response is not guaranteed. Also, there's no barrier to people
asking questions about unsupported versions - people are still asking
questions about Firefox 3.0 and getting answers (the answers generally
include a suggestion to upgrade). I've seen people get help with Windows
problems that are little to do with Firefox.

So, given that it's mostly peer support, I don't see how it would be
possible to offer less support for some versions than others. I guess
you could tell volunteers that they are not allowed to discuss old
versions, but going to additional effort in order to try and reduce
support for ESR doesn't sound sensible...

Michael
Re: Proposal to Provide an Extended Support Release of Firefox for Managed Deployments Robert Kaiser 11/24/11 3:46 AM
Henri Sivonen schrieb:
> Oh, and if ESR is going to get less support, it probably shouldn't be
> named *Extended* *Support* Release. :-)

OK, I take everything back, this doesn't lead anywhere reasonable. ;-)

I guess there's no good way of putting "our engineers might not look
into bugs that only affect ESR unless they're really really really bad,
we won't do crash report analysis for ESR, etc." into a warning that
makes sense for users and doesn't scare off organized deployments in
unwarranted ways.
Re: Proposal to Provide an Extended Support Release of Firefox for Managed Deployments Kev Needham 11/24/11 7:36 AM
To add a little clarification, one of the challenges that the orgs we've
spoken with have pointed out is that their desktop support teams provide
end-user support for everything. Having a release that provides a known
feature set helps, because maintains a baseline, and feature
updates/support training can be planned for.

We're not supporting it less, and I hope the proposal spells out exactly
what the ESR is intended to address and how it will be supported. If it
hasn't, I've failed mightily (but I'm willing to say it does, and I
haven't).

David Tenser has also weighed in on support in this thread, and the
information in SUMO for a given release will apply to the ESR it's based
on. We'll try to do the right thing , but there are differences between
the ESR and regular release, which is why we want to do everything we
can to ensure that people don't unknowingly end up on the ESR.

And yes, total bikeshed :) We're supporting the codebase to meet the
expressed needs. If there's a bug that fucks the UX terribly and address
practically, I'd hope (and be a proponent of) fixing it vs. saying "oh,
sorry. you're on that thing. sucks to be you." would be our response,
because I think we actually want to keep the nose married to the face,
and pretty much everyone else I've spoken to about it thinks similarly.

k
Re: Proposal to Provide an Extended Support Release of Firefox for Managed Deployments PhillipJones 11/24/11 9:06 AM
Not Trolling speaking my peace, expressing my opinion. There is a
difference.

I know what Trolling is and isn't.
Re: Proposal to Provide an Extended Support Release of Firefox for Managed Deployments nhirata_bz 11/24/11 2:12 PM
As my own personal opinion, I would suggest getting data to support your
opinions or your side of the story.

The purpose of the proposal is to help with corporate needs/wants.
Stating just "this won't help" isn't going to help the matters.

Answering the questions : "Why will it not help?", and "how can we make
it work?" can turn an opinion from sounding like a troll to something
that would help things move forward.

Perhaps this is off topic and should be moved to a different segment.
Again, this is my own opinion.

Regards,
Naoki Hirata
Re: Proposal to Provide an Extended Support Release of Firefox for Managed Deployments Steve Wendt 11/25/11 10:26 AM
On 11/24/2011 2:50 AM, Michael Lefevre wrote:

> I guess you could tell volunteers that they are not allowed to
> discuss old versions

Telling volunteers what they are allowed to discuss is a great way to
lose them.
Re: Proposal to Provide an Extended Support Release of Firefox for Managed Deployments Philip Chee 11/25/11 11:31 AM
I think you need more iron(y) in your diet.

Phil

--
Philip Chee <phi...@aleytys.pc.my>, <phili...@gmail.com>
http://flashblock.mozdev.org/ http://xsidebar.mozdev.org
Guard us from the she-wolf and the wolf, and guard us from the thief,
oh Night, and so be good for us to pass.
Re: Proposal to Provide an Extended Support Release of Firefox for Managed Deployments Brian Smith 11/27/11 1:57 AM
Schools are the most important target demographic for extended support that I can think of. Have we talked to any IT administrators of large school districts to see if this policy seems reasonable to them? From what I know from indirectly working with Conroe (TX) ISD, this policy would be totally inadequate for them. See below for details.

Kev Needham wrote:
> - Lengthening the support tail to 9 release cycles (54 weeks), which
> would provide a full year coverage to orgs, which was identified as
> something which would facilitate release planning and adoption in a
> number of orgs
> - Basing the initial ESR on Firefox 10.

Schools, especially US K-12 schools, need an ESR release that spans from summer to summer. From what I know, it is typical for a public school IT team to expect that they will have a stable platform to install in June and that platform will last until the following August (i.e. about 15 months). Also, a smart IT person will not install the very newest version of a browser in June; he will instead choose one that is at least somewhat proven and probably would prefer one that has at least one point release already. AFAICT, that means public school IT departments will need ~16-18 months, and anything less than 15 months is almost an automatic disqualification.

> - Changing the commitment to patch sg:Crits and sg:Highs to something
> akin to reasonable efforts, as there may be some changes that cannot
> be readily backported

At any large organization I've worked at or with, school or commercial enterprise, a policy of potentially leaving critical security vulnerabilities would automatically disqualify a product. Fixing or providing reasonable workarounds for *all* exploitable security vulnerabilities is the very minimum of what "supported" means.

- Brian
Re: Proposal to Provide an Extended Support Release of Firefox for Managed Deployments Daniel Veditz 11/28/11 6:43 PM
On 11/27/11 1:57 AM, Brian Smith wrote:
> Kev Needham wrote:
>> - Changing the commitment to patch sg:Crits and sg:Highs to
>> something akin to reasonable efforts, as there may be some
>> changes that cannot be readily backported
>
> At any large organization I've worked at or with, school or
> commercial enterprise, a policy of potentially leaving critical
> security vulnerabilities would automatically disqualify a
> product. Fixing or providing reasonable workarounds for *all*
> exploitable security vulnerabilities is the very minimum of what
> "supported" means.

Most of the bugs we internally rate "sg:critical" would be
considered "moderate" when evaluated according to more common IT
criteria like DREAD (Damage potential, Reproducibility,
Exploitability, Affected users, Discoverability). Internally we use
basically "Damage potential" and ignore the modifiers that tend to
result in arguments over guesses since it's far more effective to
fix bugs than argue about them. It's hard to imagine a case where we
would not back-port the fix for a bug that was conventionally
understood as "critical".

-Dan Veditz
Re: Proposal to Provide an Extended Support Release of Firefox for Managed Deployments Stormy Peters 12/7/11 6:42 AM
On Sun, Nov 27, 2011 at 2:57 AM, Brian Smith <bsm...@mozilla.com> wrote:

> Schools are the most important target demographic for extended support
> that I can think of. Have we talked to any IT administrators of large
> school districts to see if this policy seems reasonable to them? From what
> I know from indirectly working with Conroe (TX) ISD, this policy would be
> totally inadequate for them. See below for details.
>
> Kev Needham wrote:
> > - Lengthening the support tail to 9 release cycles (54 weeks), which
> > would provide a full year coverage to orgs, which was identified as
> > something which would facilitate release planning and adoption in a
> > number of orgs
> > - Basing the initial ESR on Firefox 10.
>
> Schools, especially US K-12 schools, need an ESR release that spans from
> summer to summer. From what I know, it is typical for a public school IT
> team to expect that they will have a stable platform to install in June and
> that platform will last until the following August (i.e. about 15 months).
> Also, a smart IT person will not install the very newest version of a
> browser in June; he will instead choose one that is at least somewhat
> proven and probably would prefer one that has at least one point release
> already. AFAICT, that means public school IT departments will need ~16-18
> months, and anything less than 15 months is almost an automatic
> disqualification.
>
> There are a number of schools represented on the Enterprise Working Group
mailing list. Mostly universities. They've all been consulted on this and
asked to weigh in.

Stormy
More topics »