Henri Sivonen wrote:
The comments on
https://bugzilla.mozilla.org/show_bug.cgi?id=1175546 suggest that
Mozilla deferred relying on GCC bug fixes until after 45 ESR in
order for Debian not to have to backport a compiler for
oldstable. Is that the case? That is, is Debian's policy already
hindering Mozilla's ability to avoid C++ compiler bugs that the
compiler upstream has fixed?
... Longer version:
It definitely is not just Debian. With all due respect, Mozilla
doesn't rule an isolated island - like all others it shares a
jungle with other animals of varying sizes, shapes and habits.
Yes, but the Linux jungle depends on the outside for the browser
engines (Gecko, Blink and WebKit) that it relies on and the numbers
that Web developers look to assess the relevance of these engines
(which translates into whether sites are made in a way that these
engines work for Linux users) happens outside the Linux jungle.
Hm... I don't have numbers, but if I'm to believe
https://en.wikipedia.org/wiki/Comparison_of_web_browser_engines#/media/File:Usage_share_of_web_browsers_(Source_StatCounter).svg
,
I don't like what I see. I guess no one here does. But should it become
too cumbersome to package Firefox at some point something would have to
give. Let's not go there and just say I really do not want to change my
email signature.
It's not reasonable for a part of the already small jungle to be
entitled to limit the Gecko development inside and outside the jungle
to old compilers.
Well... changes can be done, but have to be announced. Which is why this
thread is a Good Thing (TM).
By the way, from the picture referenced above I think that in the layout
engines part of the jungle you (as in Firefox/Gecko) sadly are the
smaller animal for quite some time now. ESR is imho one of the (arguably
not so many) big features that are slowing down further drop.
But consider: Rust as a technology works the best on Linux. (IIRC,
debugging info works better on Linux than on Mac and it's pretty
clear that Linux and Mac are better matches for Rust development
than Windows.) It's very messed up that the tech that works the best
on Linux is the hardest to ship to users on Linux.
Saying "Linux is good, we can actually do things there, that are more
complicated elsewhere, but you are hindering our development" sound a
bit unfair. "Rust works best on Linux," you say. So that part of the
jungle that is putting some restrictions in place is actually not that
bad, right? Yet these are just parts of the overall picture and you
can't really have one without the other.
My feeling is, that you might not be fully aware that it's not just the
technology side one needs to be aware of. The all-from-source, stable
interfaces and similar policies are there for a reason. From my point of
view part of the problem are the rapid changes in rustc, requiring very
recent rustc for building itself (that is my take-away from this thread
so far; more on that below).
Without the LTS/Enterprise distributions Linux would be less usable,
because there would be much smaller installed base and thus less people
working on it (and consequently probably also less pressure on quality).
I'm not saying by how much, but expect such a difference to be measurable.
I'm quite sure there are problems with other compilers/systems than
just GCC/Linux, but due to their larger target user deployment and
distribution model, they are being worked around. I know it is
different (in *many* aspects), but just imagine you had to solve a
similar issue with Microsoft or Apple (i.e. them distributing
Firefox and strongly preferring to build it with what they use for
building the rest of their systems with).
I don't think a comparison with Microsoft and Apple is in the
distros' favor. Microsoft's undocumented ABI has the practical effect
of locking us to their C++ compiler, but they don't make us use just
the C++ features and compiler bugs that were available when Windows
XP shipped.
Yes, but just like GCC has bugs, MSVC has them too. That you may not be
affected doesn't make it a better development environment.
Apple promotes clang and we are at liberty to use clang from llvm.org
instead of Apple-shipped clang and we have the option to patch clang
if we need to.
As for imagining if Microsoft and Apple imposed requirements that
they don't: The important point is that they don't!
Exactly. And they are also not so good for playing with Rust.
Actually you could package Firefox for generic Linux by building your
own GCC and bundling all libraries (the whole GTK stack) into the
tarball/rpm - at some point replicating good portion of packages
installed on an average desktop system. These would be used by firefox
only and would (mostly) work (mostly) everywhere. You would actually be
doing exactly what we do for old code streams, only across multiple
distributions. You don't want to go there. Spending time on that while
it is re-done by distributions in parallel would be wasting precious
resources.
Yet back to the point: you certainly can change whichever tool you
need or want, but the timing is crucial. Stable distribution
maintainers are used to these things happening every once in a
while, so if you announce it loudly a couple of releases ahead, it
will be perfectly fine and nobody is going to complain
Not even Debian?
Your call, Mike... :)
Genrally: it can be done, it has been done in the past, and it is
additional work. One is much more fine with it, if it doesn't have to be
done hastily and clearly helps security and/or general usability.
Generally, I think it shouldn't really be perceived as: "Linux
distributions are hindering our development", rather as being
polite and respectful in a: "Let's not make much more work for them
unless it is really, really necessary" manner. Which is exactly
what shifting such a change from before to after a major ESR
release is.
Considering how quickly Rust is progressing, chances are that the
Firefox will pick up new rustc releases faster than on a 10-month
cycle, so it will probably be safe to assume that every time there a
new major release becomes ESR, it'll require a newer rustc than the
previous ESR. But a mindset of "Linux distros can just ship ESR and
deal with rustc at 10-month intervals" isn't a great solution when
the distros have a non-enterprise audience or when the distros ship
Chromium every six weeks; see below.
"Linux distros can just ship ESR and deal with rustc at 10-month
intervals" is not exactly the right interpretation - and it might
actually be the point where we are not understanding each other.
Distributions should be fine with 6 weeks, if changes are announced with
reasonable time buffer. In some cases -aurora -> -release time frame
doesn't have to be enough (packaging rustc is such a case). Most of
distributions ship main releases, some do ESR on top of that. So 6 weeks
clearly is viable now.
Having say rustc-X and rustc-X+4 for FF-Y and FF-Y+7 (which is the ESR
stepping), shouldn't be such a problem either (although it does add
quite some work especially of you can't build rustc-X+4 with rustc-X
directly)
I think both sides want to achieve the same in the end: having a
stable and secure Firefox.
It's not clear that that's the case when it comes to what "stable"
actually means. If "stable" means "doesn't crash", sure. If "stable"
means "out-of-date", the goals may not be aligned. There is a strong
tendency towards "out-of-date" being seen as presumptively good in
the enterprise space and Mozilla already accommodating that with
ESR.
Stable for LTS/enterprise means: doesn't change existing interfaces and
functionality. As in: f(x) is always be available, does f(x) and only
f(x). As far as I understand, rustc is not in this area yet when a
timeframe of the order of months/years is considered. I suppose it will
one day, otherwise all that work would be for nothing since it would
become another (arguably worse) C++ (as far as feature creep goes).
The tendency to equate stability with out-of-date you mention usually
comes from people who haven't experienced servicing long-running
systems. Compared to Mozilla (as in codebase, development speed and
such) it is completely different world. Not better, not worse. Different.
However, when ESR spills over to a non-enterprise space (or to an
enterprise that can entertain the idea of using Chrome/Chromium on a
six-week update cycle), then having Firefox be "stable" as in
"out-of-date" is not well aligned with moving the Web forward or
being competitive with Chrome. That's why I think only shipping ESR
would not be a good mechanism to deal with the upcoming rustc build
dependency.
I'm not sure you are fully aware of the main reason behind ESR. It is
mostly testing internal enterprise web applications and add-ons, which
often takes over a month. For exactly this reason there is a 3 months
overlap (or even 4.5 if one counted -beta) and some 9 months of support.
I think most enterprises, given only the option to update every 6 weeks,
would choose to skip updates. And by skip I mean not for 9 months but
for 3 years straight. Implications would be rather obvious.
This actually also suggests that it is better to leave more fundamental
changes in functionality the releases shortly after ESR release - e.g.
say ESR+1 to ESR+3, while introducing implementation details (rewriting
C/C++ into Rust) shortly before or with ESR release (to make ESR
maintenance easier). And announce those early (I don't think this can be
overstated).
Thanks
Kind regards
Petr
--
Petr Cerny
Mozilla/OpenSSH maintainer for SUSE Linux
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
