This would require a new update channel to support, because it would be a unique line of code that isn't "release" or "esr".

It couldn't be implemented as a relbranch either, because we'd need CI for it. You're basically proposing a long lived esr-like branch that we only ship to XP users.

I suspect that backporting to this would get very difficult very quickly. We'd be better off moving XP to ESR IMO.

On 2016-04-20 02:53 PM, Armen Zambrano G. wrote:
Would it make more sense to have a relbranch instead of using ESR?
IIRC ESRs are stable for a period but when we uplift we uplift
everything new.
For this XP relbranch we would only take security patches.

It would serve the purpose of keeping our users secure where they're but
saving some energy in making new features also XP compatible.

Setting an N months EOL expectation (plus another criteria[s]) might be
wise rather than leaving it open ended.

regards,
Armen

On 16-04-20 11:46 AM, Henri Sivonen wrote:
On Mon, Apr 18, 2016 at 4:46 PM, Thomas Zimmermann
<tzimmerm...@mozilla.com> wrote:
And XP still runs on ~10% of all desktops. That's an opportunity to
convert some of the users to Firefox.

This assumes that

1) users who are still on XP still make active browser choices
2) ESR wouldn't be good enough to for these users
3) XP will still run ~10% of desktops in 11 months.

(FWIW, StatCounter puts XP's Web usage share of desktop closer to 7%
than 10%.)

On Mon, Apr 18, 2016 at 7:56 PM, Milan Sreckovic
<msrecko...@mozilla.com> wrote:
What’s the “XP tax”?

It's our attention being diverted to being backward-looking instead of
forward-looking by a thousand cuts. Here are some examples off the top
of my head:

  * We don't have EME-style DRM on XP, but if we hadn't even tried to
accommodate XP, we could have avoided some grief. (For obvious
reasons, I'm not going to elaborate on this on this list.)

  * The Rust team has had to do extra work to support XP, since XP is a
Firefox product requirement.

  * Lack of SSE2, though not an XP problem per se, coincides with XP,
so we could just require SSE2 if we didn't support XP.

  * XP failing to preserve register state on newer CPUs caused an
investigation like
https://bugzilla.mozilla.org/show_bug.cgi?id=1263495#c13

Obviously, none of the above alone seems decisive, but those are just
a few recent things that I can think of without searching. I'm sure
there are a lots and lots of things, each smallish taken alone, but
they add up and take our collective attention away from making our
product better on current systems. Moving XP to ESR would liberate us
from thinking of some of them, but, granted, we might feel compelled
to figure out stuff like the AVX thing even on ESR. Also, some of the
above are sunk cost now, but my point is that as long as XP is treated
as supported, it can inflict new analogous costs on us.

On Tue, Apr 19, 2016 at 11:24 PM, Kyle Huey <m...@kylehuey.com> wrote:
We jump through some hoops to support things like Linux and Mac too, and
those platforms combined have far fewer users than XP.

Linux and Mac will still be as relevant in 11 months. XP's relevance
is declining. If our estimate was that XP won't be worthwhile in 11
months, putting it on ESR now would make sense compared to expending
the effort of full support over the next 11 months.




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

Reply via email to