Re: Intent to deprecate: MacOS 10.6-10.8 support

[Gabor Krizsanits]

On Thu, Mar 10, 2016 at 7:03 PM, Benjamin Smedberg 
wrote:

> This will affect approximately 1.2% of our current release population.
> Here are the specific breakdowns by OS version:
>
>
Seems like a tough decision for such a short time...  There were some great
points on both sides so far, but I'm missing the math. To evaluate the
cost/benefit for a decision like this we should be able to estimate how
much engineering time does it take for us to gain 1.2% new users and how
much does it cost to keep the support. My personal estimation for the first
is pretty high :(

We also might miss the opportunity to gain new users on these systems, and
we risk a bad press as well, but I'm a little less concerned about these. I
just feel like there should be some other way to save engineering time that
costs less users but without the metrics I can only guess.

- Gabor
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to deprecate: MacOS 10.6-10.8 support

[Lawrence Mandel]

On Sat, Mar 12, 2016 at 4:46 PM, Kyle Huey  wrote:

> On Fri, Mar 11, 2016 at 4:28 PM, Terrence Cole  wrote:
>
> > We need to drop support for OSX 10.8 and Windows Vista yesterday, not
> next
> > year. We need to cut our losses and ship E10S while we're still relevant.
> > We need to be the browser that works best on Android and Windows 10, not
> > the browser that happens to already be installed.
> >
>
> You do realize that you're talking about throwing away nearly 20% of our
> user base, right?
>
>
If the concern for user base is marketshare (as I've read and heard some
people claim, although maybe not Kyle), I'm not sure this argument holds
water for two reasons:

1. If we stop supporting an OS version today, all of the users on that
version will not immediately switch to an alternative.
2. In the case of older OSes, if there are no other browsers shipping
updates, there is really no alternative that is more attractive than the
browser that you've already picked.

Lawrence
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to deprecate: MacOS 10.6-10.8 support

[Bobby Holley]

On Fri, Mar 11, 2016 at 10:51 AM, Chris Hofmann 
wrote:

> On Fri, Mar 11, 2016 at 9:20 AM, Benjamin Smedberg 
> wrote:
>
> >
> >
> > On 3/10/2016 5:25 PM, Mike Hommey wrote:
> >
> >>
> >> It's unfair to mention those populations by percentage of the global
> >> Firefox population.
> >>
> >
> > Why do you think this is unfair? This is about making the best use of our
> > limited engineering/testing/QA resources, and so what really matters is
> the
> > total impact, not just the impact relative to the mac population.
> >
>
> The reason for considering benefits of populations relative to their own OS
> are because there are two kinds of things we get out of platform support.
>
> One is greater impact resulting from a higher overall number of users.
>
> The other is other strategic benefits we get out of platform support like
> on Linux where user numbers are low, but gecko and firefox tootling and
> testing developer contributions are relatively high.
>
> For Mac there is a possible web dev connection that's of possible strategic
> value with higher concentration of web devs on that platfor that help keep
> sites working well for large numbers of others.
>
>
>
> >
> > Dolske answered with more details about the numbers.
> >
>
>
> Dolske showed some numbers that reflects where in the decline in previous
> Mac cycles that we removed support, but that could or could not be related
> to our current problem of trying to find ways to stablize and stop the
> decline of users.
>
> Keeping these releases supported around just a bit longer than google gives
> people incentive to come back and try firefox.  Just the thing we want to
> happen.
>
> If I look a a view of the numbers relative to all current Mac users it
> looks like 10.8 has the highest value (15% of all current Mac Users) for
> keeping around just a bit longer if their is any possible way to do that.
> The others are in the noise.
>
> Some one should check these numbers and see if they look right.
>
> Version  % of all current Mac users as of back in Nov. which is the
> latest data I can easily get my hands on to play with.
>
> Mac10.8.00.1500
>
>  Mac10.7.00.0004
>  Mac10.7.40.0001
>  Mac10.7.10.0001
>  Mac10.7.30.0001
>
>  Mac10.6.00.0003
>

This does not jive with the data bsmedberg provided in the OP, which shows
the 10.6 userbase being equal to that of 10.7 and 10.8 combined.

It's also worth considering what value we could unlock by dropping 10.6 and
keeping 10.7 and above. IIUC most of the pain on the engineering side (c++
standard library, TLS for rust, etc) is related to 10.6 specifically.
Things might be different in the releng world though.


>
>
>
>
> >
> > On 3/10/2016 6:38 PM, Nils Ohlmeier wrote:
> >
> >> Excuse my ignorance, but what means “deprecate support” exactly?
> >>
> >> I’m only asking because of the opposing reply’s so far. I’m assuming it
> >> means we stop testing and building/releasing for these. Would it be a
> >> possible alternative to turn of the tests, but continue to build and
> >> release unsupported builds?
> >>
> > We intend to do the following things:
> >
> > * add version checking to the builds so that they refuse to run on these
> > versions of MacOS
> > * stop doing any software testing on these versions of MacOS
> > * stop automated testing on Mac 10.6
> >
> > As soon as we stop testing, we are going to break things. We shouldn't be
> > willing to call things "Firefox" that we aren't proud of, which includes
> > real testing.
> >
> >
> >
> > On 3/10/2016 6:49 PM, Kyle Huey wrote:
> >
> >>
> >> Why can't we just not ship e10s to these users?  We have a number of
> other
> >> populations we're not shipping to, at least for now.
> >>
> >
> > We did explicitly consider this option and ultimately rejected it. It
> > would potentially buy us at least one more ESR cycle until next January.
> > After that point we want e10s to be the only configuration. It comes at
> the
> > cost of ignoring known issues already as well as a nontrivial amount of
> > testing. Ultimately we don't believe this is the right tradeoff. It also
> > prevents us making progress on other areas such non-universal builds.
> >
> > --BDS
> >
> >
> > ___
> > firefox-dev mailing list
> > firefox-...@mozilla.org
> > https://mail.mozilla.org/listinfo/firefox-dev
> >
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to deprecate: MacOS 10.6-10.8 support

[Kyle Huey]

On Fri, Mar 11, 2016 at 4:28 PM, Terrence Cole  wrote:

> We need to drop support for OSX 10.8 and Windows Vista yesterday, not next
> year. We need to cut our losses and ship E10S while we're still relevant.
> We need to be the browser that works best on Android and Windows 10, not
> the browser that happens to already be installed.
>

You do realize that you're talking about throwing away nearly 20% of our
user base, right?

- Kyle
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to deprecate: MacOS 10.6-10.8 support

[Bobby Holley]

On Fri, Mar 11, 2016 at 5:13 PM, Bobby Holley  wrote:

>
>
> On Fri, Mar 11, 2016 at 4:28 PM, Terrence Cole  wrote:
>
>> We've had this conversation several times in the last few years and I
>> think
>> I've finally figured out why it has always felt subtly wrong.
>>
>> Our share of users on older platforms is disproportionally high compared
>> to
>> the market in general because of our decline in market share. People who
>> don't want to upgrade their OS generally don't want to "upgrade" their
>> browser to the shiny new "chrome" thing the kids are talking about either.
>> It is a symptom of a larger problem and it seems like we are continually
>> hiding from that problem instead of tackling it head-on.
>>
>> We should be aggressively cutting support for niche markets and spending
>> that effort to increase our market share where it counts: where it's
>> growing rather than rapidly shrinking. Telling 1.2% of our (admittedly
>> small) market share to, effectively, GTFO, is pretty scary; however, I
>> think the alternative is to simply fail as a project as we chase our
>> users-by-default into more and more niche markets. If we can't use our
>> resources to re-capture 1.2% of the market among people who have modern
>> computers and no obligation to love us, then maybe we've already failed.
>>
>
> I don't think it's quite that simple.
>
> I agree that it's important to recognize that users on older OSes have
> lower long-term value to us, because we'll _eventually_ need to stop
> supporting them, and there's no guarantee they'll reinstall Firefox if they
> move to a new machine.
>
> However, they _do_ have short-term value, in that their continued use of
> Firefox makes the Web better for every other Firefox user. The number of
> f***s web developers give about the experience of Firefox users is directly
> proportional to the number of Firefox users visiting their sites.
>

Though actually, I think the reality is worse than that, because the curve
is probably non-linear. There's probably some relatively-discrete point
(which we can't easily predict) at which declaring Firefox an "unsupported
browser" becomes a sensible business decision for large, enterprise-y sites
that operate that way.

We should try very hard to stay above that threshold. I don't know how much
closer to it this proposal will bring us, but it's definitely more than
1.2%.


> The lower that number goes, the bigger our disadvantage, and the more
> engineering heroics we'll need to do to compensate. By the time
> Opera/Presto went under, rumor has it that almost all of their resources
> were going to web-compat.
>
> Its a regressive game that favors monopolists, but there you go. Ditching
> 1.2% of our users makes it materially more difficult to attract new ones.
> So we should only do it if the benefits really outweigh the costs.
>
> I'm happy to be more aggressive about ignoring 10.6-only regressions,
> reducing testing, etc. If it keeps the costs manageable, I think it's
> preferable to ship a possibly-sub-par experience to 10.6 users than to
> jettison them entirely.
>
> bholley
>
>
>> We need to drop support for OSX 10.8 and Windows Vista yesterday, not next
>> year. We need to cut our losses and ship E10S while we're still relevant.
>> We need to be the browser that works best on Android and Windows 10, not
>> the browser that happens to already be installed.
>>
>> My 2 cents,
>> :terrence
>>
>>
>> On Fri, Mar 11, 2016 at 9:20 AM, Benjamin Smedberg > >
>> wrote:
>>
>> >
>> >
>> > On 3/10/2016 5:25 PM, Mike Hommey wrote:
>> >
>> >>
>> >> It's unfair to mention those populations by percentage of the global
>> >> Firefox population.
>> >>
>> >
>> > Why do you think this is unfair? This is about making the best use of
>> our
>> > limited engineering/testing/QA resources, and so what really matters is
>> the
>> > total impact, not just the impact relative to the mac population.
>> >
>> > Dolske answered with more details about the numbers.
>> >
>> > On 3/10/2016 6:38 PM, Nils Ohlmeier wrote:
>> >
>> >> Excuse my ignorance, but what means “deprecate support” exactly?
>> >>
>> >> I’m only asking because of the opposing reply’s so far. I’m assuming it
>> >> means we stop testing and building/releasing for these. Would it be a
>> >> possible alternative to turn of the tests, but continue to build and
>> >> release unsupported builds?
>> >>
>> > We intend to do the following things:
>> >
>> > * add version checking to the builds so that they refuse to run on these
>> > versions of MacOS
>> > * stop doing any software testing on these versions of MacOS
>> > * stop automated testing on Mac 10.6
>> >
>> > As soon as we stop testing, we are going to break things. We shouldn't
>> be
>> > willing to call things "Firefox" that we aren't proud of, which includes
>> > real testing.
>> >
>> >
>> >
>> > On 3/10/2016 6:49 PM, Kyle Huey wrote:
>> >
>> >>
>> >> Why can't we just not ship e10s 

Re: Intent to deprecate: MacOS 10.6-10.8 support

[Bobby Holley]

On Fri, Mar 11, 2016 at 4:28 PM, Terrence Cole  wrote:

> We've had this conversation several times in the last few years and I think
> I've finally figured out why it has always felt subtly wrong.
>
> Our share of users on older platforms is disproportionally high compared to
> the market in general because of our decline in market share. People who
> don't want to upgrade their OS generally don't want to "upgrade" their
> browser to the shiny new "chrome" thing the kids are talking about either.
> It is a symptom of a larger problem and it seems like we are continually
> hiding from that problem instead of tackling it head-on.
>
> We should be aggressively cutting support for niche markets and spending
> that effort to increase our market share where it counts: where it's
> growing rather than rapidly shrinking. Telling 1.2% of our (admittedly
> small) market share to, effectively, GTFO, is pretty scary; however, I
> think the alternative is to simply fail as a project as we chase our
> users-by-default into more and more niche markets. If we can't use our
> resources to re-capture 1.2% of the market among people who have modern
> computers and no obligation to love us, then maybe we've already failed.
>

I don't think it's quite that simple.

I agree that it's important to recognize that users on older OSes have
lower long-term value to us, because we'll _eventually_ need to stop
supporting them, and there's no guarantee they'll reinstall Firefox if they
move to a new machine.

However, they _do_ have short-term value, in that their continued use of
Firefox makes the Web better for every other Firefox user. The number of
f***s web developers give about the experience of Firefox users is directly
proportional to the number of Firefox users visiting their sites. The lower
that number goes, the bigger our disadvantage, and the more engineering
heroics we'll need to do to compensate. By the time Opera/Presto went
under, rumor has it that almost all of their resources were going to
web-compat.

Its a regressive game that favors monopolists, but there you go. Ditching
1.2% of our users makes it materially more difficult to attract new ones.
So we should only do it if the benefits really outweigh the costs.

I'm happy to be more aggressive about ignoring 10.6-only regressions,
reducing testing, etc. If it keeps the costs manageable, I think it's
preferable to ship a possibly-sub-par experience to 10.6 users than to
jettison them entirely.

bholley


> We need to drop support for OSX 10.8 and Windows Vista yesterday, not next
> year. We need to cut our losses and ship E10S while we're still relevant.
> We need to be the browser that works best on Android and Windows 10, not
> the browser that happens to already be installed.
>
> My 2 cents,
> :terrence
>
>
> On Fri, Mar 11, 2016 at 9:20 AM, Benjamin Smedberg 
> wrote:
>
> >
> >
> > On 3/10/2016 5:25 PM, Mike Hommey wrote:
> >
> >>
> >> It's unfair to mention those populations by percentage of the global
> >> Firefox population.
> >>
> >
> > Why do you think this is unfair? This is about making the best use of our
> > limited engineering/testing/QA resources, and so what really matters is
> the
> > total impact, not just the impact relative to the mac population.
> >
> > Dolske answered with more details about the numbers.
> >
> > On 3/10/2016 6:38 PM, Nils Ohlmeier wrote:
> >
> >> Excuse my ignorance, but what means “deprecate support” exactly?
> >>
> >> I’m only asking because of the opposing reply’s so far. I’m assuming it
> >> means we stop testing and building/releasing for these. Would it be a
> >> possible alternative to turn of the tests, but continue to build and
> >> release unsupported builds?
> >>
> > We intend to do the following things:
> >
> > * add version checking to the builds so that they refuse to run on these
> > versions of MacOS
> > * stop doing any software testing on these versions of MacOS
> > * stop automated testing on Mac 10.6
> >
> > As soon as we stop testing, we are going to break things. We shouldn't be
> > willing to call things "Firefox" that we aren't proud of, which includes
> > real testing.
> >
> >
> >
> > On 3/10/2016 6:49 PM, Kyle Huey wrote:
> >
> >>
> >> Why can't we just not ship e10s to these users?  We have a number of
> other
> >> populations we're not shipping to, at least for now.
> >>
> >
> > We did explicitly consider this option and ultimately rejected it. It
> > would potentially buy us at least one more ESR cycle until next January.
> > After that point we want e10s to be the only configuration. It comes at
> the
> > cost of ignoring known issues already as well as a nontrivial amount of
> > testing. Ultimately we don't believe this is the right tradeoff. It also
> > prevents us making progress on other areas such non-universal builds.
> >
> > --BDS
> >
> >
> > ___
> > dev-platform mailing list
> > 

Re: XULRunner future and ownership

[段垚]

Hi,

For those who are still interested in XULRunner, I created a project to 
maintain the source of xulrunner-stub, and build against Firefox SDK. 
Here is the link:

https://github.com/duanyao/xulrunner-stub

Currently only win32 is supported, and Firefox 47a2 is tested.

I'd like to ask Mozilla people: will this route work for next 2 or 3 years?

在 2016/2/22 15:28, m.bauermeis...@sto.com 写道:

Is building the runtime manually still an option? If so, how would I go about 
it? Are the relevant sources all merged into the Firefox repository?
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform



___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: XULRunner future and ownership

[段垚]

Hi,

For those who are still interested in XULRunner, I created a project to 
maintain the source of xulrunner-stub, and build against Firefox SDK. 
Here is the link:

https://github.com/duanyao/xulrunner-stub

Currently only win32 is supported, and Firefox 47a2 is tested.

I'd like to ask Mozilla people: will this route work for the next 2 or 3 
years?


在 2016/2/22 15:28, m.bauermeis...@sto.com 写道:

Is building the runtime manually still an option? If so, how would I go about 
it? Are the relevant sources all merged into the Firefox repository?
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform



___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: XULRunner future and ownership

[段垚]

Hi,

For those who are still interested in XULRunner (especially the stub), I 
created a project to continue to build xulrunner-stub with Firefox SDK. 
Here is the link:

https://github.com/duanyao/xulrunner-stub .

I extracted xulrunner/stub/nsXULStub.cpp, xpcom/build/nsXPCOMPrivate.h , 
toolkit/xre/nsWindowsWMain.cpp and build them with Firefox SDK, and it seems
to work well. However, I'd like to ask Mozilla pepole: will this route 
keep feasible in the coming 2-3 years?


在 2016/2/22 15:28, m.bauermeis...@sto.com 写道:

Is building the runtime manually still an option? If so, how would I go about 
it? Are the relevant sources all merged into the Firefox repository?
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform



___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to implement: W3C WebAppSec credentialmanagement API

[Anne van Kesteren]

On Sat, Mar 12, 2016 at 3:48 AM, Martin Thomson  wrote:
> Now that is a frightening observation. Is this creating a more persistent
> (pernicious?) tracking mechanism?

It should be identical to password manager integration.


> In that case, credentials stored by a site should last no longer than
> cookies. Credentials created by a user maybe can live longer.

How do you distinguish the two if the access is through a UI-mediated API?


If we think this API should have no more power than storage/cookies,
there's not much point in having this API. A site could then simply
remember the federation provider itself, and such, and lose it
whenever the user is done with the site (or has visited enough other
sites).


-- 
https://annevankesteren.nl/
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform