On Fri, Mar 11, 2016 at 10:51 AM, Chris Hofmann <chofm...@mozilla.com> wrote:
> On Fri, Mar 11, 2016 at 9:20 AM, Benjamin Smedberg <benja...@smedbergs.us> > 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.0 0.1500 > > Mac10.7.0 0.0004 > Mac10.7.4 0.0001 > Mac10.7.1 0.0001 > Mac10.7.3 0.0001 > > Mac10.6.0 0.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