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

classic Classic list List threaded Threaded
176 messages Options
1234 ... 9
Reply | Threaded
Open this post in threaded view
|

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

Kev Needham-2
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
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

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

David E. Ross-3
On 9/21/11 2: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)

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
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

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

Justin Scott-7
In reply to this post by Kev Needham-2
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 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
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

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

Kev Needham-2
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.

_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

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

L. David Baron
In reply to this post by Kev Needham-2
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/   𝄂
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

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

Kev Needham-2
In reply to this post by Kev Needham-2
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.
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

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

Kyle Huey-2
In reply to this post by Kev Needham-2
On Wed, Sep 21, 2011 at 5:13 PM, Kev Needham <[hidden email]> 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
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

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

Jonas Sicking-2
On Wed, Sep 21, 2011 at 3:23 PM, Kyle Huey <[hidden email]> wrote:

> On Wed, Sep 21, 2011 at 5:13 PM, Kev Needham <[hidden email]> 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.

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
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

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

Jonas Sicking-2
In reply to this post by Kev Needham-2
On Wed, Sep 21, 2011 at 2:13 PM, Kev Needham <[hidden email]> 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
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

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

Axel Hecht
In reply to this post by Kev Needham-2
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
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

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

Dave Mandelin-2
In reply to this post by Kev Needham-2
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
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

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

Christian Legnitto
In reply to this post by Jonas Sicking-2

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

> On Wed, Sep 21, 2011 at 2:13 PM, Kev Needham <[hidden email]> 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
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

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

Jonas Sicking-2
On Wed, Sep 21, 2011 at 5:16 PM, Christian Legnitto
<[hidden email]> wrote:

>
> On Sep 21, 2011, at 5:09 PM, Jonas Sicking wrote:
>
>> On Wed, Sep 21, 2011 at 2:13 PM, Kev Needham <[hidden email]> 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
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

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

alonmozilla (Bugzilla)
In reply to this post by Kev Needham-2
On Sep 21, 3:23 pm, Kyle Huey <[hidden email]> 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
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

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

Cheng Wang-2
In reply to this post by Kyle Huey-2
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?

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

_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

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

Boris Zbarsky
In reply to this post by Dave Mandelin-2
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


_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

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

Christian Legnitto
In reply to this post by Cheng Wang-2
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

On Sep 21, 2011, at 6:45 PM, Cheng Wang <[hidden email]> wrote:

> 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?
>
>>
>> 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
>
> _______________________________________________
> dev-planning mailing list
> [hidden email]
> https://lists.mozilla.org/listinfo/dev-planning
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

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

Millwood
In reply to this post by Kev Needham-2
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.
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

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

Cheng Wang-2
In reply to this post by 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

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.

>
> Thanks,
> Christian
>
> On Sep 21, 2011, at 6:45 PM, Cheng Wang <[hidden email]> wrote:
>
> > 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?
> >
> >>
> >> 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
> >
> > _______________________________________________
> > dev-planning mailing list
> > [hidden email]
> > https://lists.mozilla.org/listinfo/dev-planning
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

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

Christian Legnitto


On Sep 21, 2011, at 8:08 PM, Cheng Wang <[hidden email]> 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

>
>>
>> Thanks,
>> Christian
>>
>> On Sep 21, 2011, at 6:45 PM, Cheng Wang <[hidden email]> wrote:
>>
>>> 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?
>>>
>>>>
>>>> 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
>>>
>>> _______________________________________________
>>> dev-planning mailing list
>>> [hidden email]
>>> https://lists.mozilla.org/listinfo/dev-planning
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
1234 ... 9