Hello,
my first post, so let me introduce myself briefly: I've been with SUSE
Linux as Mozilla (currently Firefox+NSPR/NSS) maintainer for SLE (SUSE
Linux Enterprise Server/Desktop) for some five years.
Henri Sivonen wrote:
But as a matter of fact, Debian's old stable is not
receiving Blink/Chromium updates (it's stuck on 37), while it receives
updates for Iceweasel (it has 38.7 as or writing, will receive 38.8, and
45.2 after that)
It appears that 45 ESR compiles with the GCC version that's in
oldstable. What would have happened if that wasn't the case? What's
the plan if during the support cycle of the current stable the next
ESR doesn't build with the GCC version that shipped in current stable?
I can't speak for Debian, but on SLE the solution we went for last time
was packaging new-enough GCC for older supported code streams, very much
like other packages (e.g. GTK) we had already needed way before. It
wasn't entirely painless - to give you some context: both SUSE and
RedHat have a 10+ years support, while Debian has 3 and Ubuntu LTS 5 years.
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?
TL;DR version: change whatever you need, but please do announce the
intent loudly, clearly and early enough.
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. 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).
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 (especially when you give clear reasons),
since there will be enough time to prepare for the change.
If you decided to introduce such a change couple of weeks before an ESR
release date, you wouldn't want to go anywhere near the maintainers of
older long-term-supported systems.
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. If you really need
to "break things" in the above sense, please do communicate it
thoroughly and early enough, for as small as the Firefox-on-Linux
userbase might be by percentage, that percentage is still calculated
from a quite large base.
I think both sides want to achieve the same in the end: having a stable
and secure Firefox. That we may be coming from opposite sides (doing
quick development with bleeding edge technologies versus supporting
systems for 3+ years) need not matter that much. The key is trying to
understand the other party's context (to give an example: while I had
been rather sceptical about Rustification, after reading up a bit on the
topic and some conversations with people who have deeper insight, many
of my reservations were gone).
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
