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

[Kev Needham]

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

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

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

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

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

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

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

Kev Needham (also representing Stormy Peters and JP Rosevear)

[David E. Ross]

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

--

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

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

[Justin Scott]

Hi Kev,

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

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

Justin

[Kev Needham]

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

That's my intent for this proposal, yes.

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

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

[L. David Baron]

On Wednesday 2011-09-21 17:13 -0400, Kev Needham wrote:
> The proposal can be viewed on the Mozilla Wiki at
> https://wiki.mozilla.org/Enterprise/Firefox/ExtendedSupport:Proposal. I
> think it balances the needs of organization(s) that want to continue to
> deploy Firefox, while allowing Mozilla to maintain a faster release
> process to better deliver new features, performance enhancements and
> security fixes to individual users.

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

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

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

-David

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

[Kev Needham]

On 11-09-21 5:54 PM, L. David Baron wrote:
> On Wednesday 2011-09-21 17:13 -0400, Kev Needham wrote:
>> The proposal can be viewed on the Mozilla Wiki at
>> https://wiki.mozilla.org/Enterprise/Firefox/ExtendedSupport:Proposal. I
>> think it balances the needs of organization(s) that want to continue to
>> deploy Firefox, while allowing Mozilla to maintain a faster release
>> process to better deliver new features, performance enhancements and
>> security fixes to individual users.
>
> I think this proposal looks great; it's reflects what I was hoping
> we'd do.
>
> However, I'm confused by the use of version numbers associated with
> the ESR releases. It's not clear in the proposal what, if anything,
> those version numbers are intended to mean. Is the intent that
> they're something that would be exposed in any way to users or Web
> developers? I had hoped that what would be exposed to Firefox users
> and to Web developers would be versions that correspond to the
> Firefox/Gecko version numbers, more like 8, 8.1, 8.2, etc. Is the
> proposal implying that's not the case?

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

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

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

[Kyle Huey]

On Wed, Sep 21, 2011 at 5:13 PM, Kev Needham <k...@mozilla.com> wrote:

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

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

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

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

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

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

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

- Kyle

[Jonas Sicking]

On Wed, Sep 21, 2011 at 3:23 PM, Kyle Huey <m...@kylehuey.com> wrote:
> On Wed, Sep 21, 2011 at 5:13 PM, Kev Needham <k...@mozilla.com> wrote:
>

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

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

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

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

/ Jonas

[Axel Hecht]

My POV from l10n:

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

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

Axel

[Jonas Sicking]

On Wed, Sep 21, 2011 at 2:13 PM, Kev Needham <k...@mozilla.com> wrote:
> The proposal can be viewed on the Mozilla Wiki at
> https://wiki.mozilla.org/Enterprise/Firefox/ExtendedSupport:Proposal. I
> think it balances the needs of organization(s) that want to continue to
> deploy Firefox, while allowing Mozilla to maintain a faster release
> process to better deliver new features, performance enhancements and
> security fixes to individual users.

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

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

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

/ Jonas

[David Mandelin]

I like the general idea, but I have a few questions about the details:

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

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

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

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

Dave

[Christian Legnitto]

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

> On Wed, Sep 21, 2011 at 2:13 PM, Kev Needham <k...@mozilla.com> wrote:

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

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

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

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

Thanks,
Christian

[Jonas Sicking]

On Wed, Sep 21, 2011 at 5:16 PM, Christian Legnitto
<cleg...@mozilla.com> wrote:
>
> On Sep 21, 2011, at 5:09 PM, Jonas Sicking wrote:
>
>> On Wed, Sep 21, 2011 at 2:13 PM, Kev Needham <k...@mozilla.com> wrote:

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

>> One thing that is not clear in the proposal is if there will be aurora
>> or nightly-like channels for ESR. Before we switched to the rapid
>> release model, we had nightly and beta channels for a given release.
>> I.e. there's a nightly channel for the dot-releases for 3.6, as well
>> as a beta channel for the dot-releases for 3.6.
>
> This is covered in the proposal in the risks section. Even if we had testers it will be nowhere near the amount we want. Currently we have 80k Firefox 3.6 beta testers and ~10k 3.6 nightly testers....not nearly enough to be confident in quality. We expect those numbers to be a lot lower for ESR.

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

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

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

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

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

/ Jonas

[Cheng Wang]

Jonas Sicking wrote:

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

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

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

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

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

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

[Boris Zbarsky]

On 9/21/11 8:16 PM, David Mandelin wrote:
> I like the general idea, but I have a few questions about the details:

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

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

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

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

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

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

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

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

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

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

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

-Boris

[Christian Legnitto]

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

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

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

4. Car analogies...yikes ;-)

Thanks,
Christian

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

[Millwood]

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

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

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

[Cheng Wang]

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

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

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

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

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

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

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

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

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

[azakai]

On Sep 21, 3:23 pm, Kyle Huey <m...@kylehuey.com> wrote:
> My main concern with this is splitting our user base between the two
> releases

Me too.

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

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

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

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

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

- azakai

[Christian Legnitto]

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Thanks,
Christian

[Justin Lebar]

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

> to hide it.

Could you elaborate on these barriers?

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

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

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

[Henri Sivonen]

On Thu, Sep 22, 2011 at 12:13 AM, Kev Needham <k...@mozilla.com> wrote:
> The proposal can be viewed on the Mozilla Wiki at
> https://wiki.mozilla.org/Enterprise/Firefox/ExtendedSupport:Proposal

Thank you for putting this together!

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

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

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

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

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

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

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

[Mike Ratcliffe]

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

~Mike Ratcliffe

[Mike Hommey]

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

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

Mike

[deep64blue]

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

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

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

Regards

Alan

[deep64blue]

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

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

Alan

[deep64blue]

On Sep 21, 10:13 pm, Kev Needham <k...@mozilla.com> wrote:
>
> I thank you in advance for your thoughts and feedback, and look forward
> to a constructive discussion.

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

I have two concerns:-

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

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

Thanks again for bringing some sanity to this mess.

Alan

[Mike Hommey]

Supposedly, once you installed it, it would upgrade itself
automatically, and without your friends and family notices. What bothers
me, is that this would work well if we weren't making disruptive changes
to the UI. I'm pretty convinced a lot of people, me included, are going
to be bothered with the new behaviour for the forward button currently
in Nightly.

Mike

[Henri Sivonen]

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

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

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

[JP Rosevear]

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

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

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

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

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

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

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

Indeed.

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

[JP Rosevear]

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

(Again, using Kev's diagram).

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

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

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

[Henri Sivonen]

On Thu, Sep 22, 2011 at 4:27 PM, JP Rosevear <j...@mozilla.com> wrote:
> It is, but the overlap time frame is important as well because that is
> when "qualification" of the new browser happens.

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

[JP Rosevear]

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

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

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

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

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

[Dao]

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

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

[Kev Needham]

On 11-09-21 8:09 PM, Jonas Sicking wrote:
> On Wed, Sep 21, 2011 at 2:13 PM, Kev Needham<k...@mozilla.com> wrote:
>> The proposal can be viewed on the Mozilla Wiki at
>> https://wiki.mozilla.org/Enterprise/Firefox/ExtendedSupport:Proposal. I
>> think it balances the needs of organization(s) that want to continue to
>> deploy Firefox, while allowing Mozilla to maintain a faster release
>> process to better deliver new features, performance enhancements and
>> security fixes to individual users.
>
> One thing that is not clear in the proposal is if there will be aurora
> or nightly-like channels for ESR. Before we switched to the rapid
> release model, we had nightly and beta channels for a given release.
> I.e. there's a nightly channel for the dot-releases for 3.6, as well
> as a beta channel for the dot-releases for 3.6.

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

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

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

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

Yup, and ideally users, too.

k

[Kev Needham]

Ideally they will be testing on Aurora and Beta of the base release, and
will let us know of issues they encounter. It means we need to improve
messaging around what's coming, but the predictability of the release
dates will hopefully help there.

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

k

[Kev Needham]

That is my proposal, yes.

[Kev Needham]

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

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

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

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

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

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

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

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

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

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

k

[Boris Zbarsky]

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

"Firefox for Managed Deployments" is presumably too clunky?

"Firefox Managed Edition"?

-Boris

[Pascal Chevrel]

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

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

Pascal

[Mike Hommey]

On Thu, Sep 22, 2011 at 10:12:11AM -0400, Kev Needham wrote:
> That is my proposal, yes.

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

Mike

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

[WLS]

Firefox Enterprise Edition?

--

SeaMonkey

[David E. Ross]

First of all, I install updates when it is convenient for me, not when
it is convenient for developers. For that, I disable any preferences
for automatic download and installation.

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

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

--

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

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

[Joshua Cranmer]

On 9/22/2011 9:34 AM, Kev Needham wrote:
> We're expecting them to distribute Mozilla Firefox. The ESR is a
> modified version of Firefox, and my thoughts are that it's not
> something we'd approve for distribution in a public distro. The ESR is
> targeted at organizations, not individuals, and for public
> distributions the expectation is that they'd continue to ship Mozilla
> Firefox.

So if a distribution provides moderate long-term support for a branch,
then they are unable to even use the ESR versions of Firefox on that
long-term supported branch? There are also distributions primarily
targeted at organizations--e.g., RHEL; should the fact that they are a
Linux distribution per se disqualify them from using an ESR version of
Firefox?

[Johnathan Nightingale]

I don't want to go point for point on the various replies here, but I wanted to address some common threads so that Kev doesn't have to do ALL the typing.

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

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

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

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

3) Won't our users flock to ESR?

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

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

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

5) I hate updates.

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

J

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

> Since moving to a faster release process, Mozilla understands that some
> organizations are facing challenges in deploying Mozilla products in a
> managed environment. The faster release cadence makes gives organizations a shorter period of time to certify and use new releases,
> and the lack of maintenance on older releases can expose organizations
> using them to security risks. Through the Enterprise Working Group (EWG)
> we're working with those organizations through to determine the best way
> Mozilla can help.
>
> To that end, representatives from the Product, Engagement, Engineering,
> and Release Engineering teams have taken the feedback received to date
> from the EWG and other sources to create an initial proposal for an Extended Support Release (ESR) of Mozilla Firefox and Thunderbird. These proposed releases would provide organizations with additional time to certify and deploy new versions of Firefox while mitigating some of the security risks of staying on an older release. They would be targeted specifically at those organizations that want to deploy Firefox and Thunderbird in a managed environment, and would not be recommended for individuals outside those organizations.

>
> The proposal can be viewed on the Mozilla Wiki at

> https://wiki.mozilla.org/Enterprise/Firefox/ExtendedSupport:Proposal. I
> think it balances the needs of organization(s) that want to continue to
> deploy Firefox, while allowing Mozilla to maintain a faster release
> process to better deliver new features, performance enhancements and
> security fixes to individual users.
>

> The proposed ESR will require effort to maintain, and we want to gather
> feedback in dev.planning from the broader Mozilla project on the
> proposal and its impacts. When submitting your feedback, please consider how it balances our need to give individuals the best experience possible through our regular release process while still meeting the needs of organizations that deploy Mozilla software; how it affects you and the people you work with; and what additional clarity we can provide on the ideas behind the proposal.
>
> We realize that Thunderbird in particular is a significant downstream consumer of the Gecko platform, which is itself influenced by Firefox's plans with respect to security & maintenance policies in particular. While sharing technology, Thunderbird is a distinct product which is exposed to different distinct security and market environments, and we don't want to assume that the discussions which have focused on Firefox necessarily apply as-is to Thunderbird. We will be starting a Thunderbird-specific discussion informed by the Firefox processes, please join that discussion on the tb-enterprise mailing list (https://wiki.mozilla.org/Thunderbird/tb-enterprise).
>
> I'll be compiling, responding to, and evaluating the feedback received
> on the ESR proposal, and will provide updates here on the go-forward plan, including suggested changes. I hope to be able to provide the project with the information it needs to take a decision on the ESR within the next few weeks, and would ask for your feedback as soon as possible. If you're not comfortable posting to the dev.planning
> group, please also feel free to contact me directly.

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

> Kev Needham (also representing Stormy Peters and JP Rosevear)

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

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

<