Recently, build issues appeared in Firefox on non-x86 architectures. As a result, the maintainer (@stransky) opted for dropping the other architectures from the build in favor of shipping the x86 versions immediately.
This raised issues that would be potentially blocking in Fedora, such as https://bugzilla.redhat.com/show_bug.cgi?id=1448923 . I'll note that the ARMv7 build has been re-enabled at this time, but aarch64, ppc64[le] and s390x are all still unavailable.
Fedora QA has determined that missing Firefox is not strictly against the blocker criterion as they are currently defined. They have also been unwilling to entertain my proposal for a new, broader criterion requiring us to have the same packages available in all default installs. Given Firefox's relative importance in the stack, I'd like to propose that https://bugzilla.redhat.com/show_bug.cgi?id=1443938 be declared a blocker issue by FESCo's override.
I feel that Firefox is sufficiently critical to our success as a distribution that not shipping it on all supported architectures would be a harmful outcome.
Shouldn't any Critpath package supposed to build on all the architectures if not building now with any new update be considered as blocker bug?
The critpath concept hasn't been in effect for some time now (ever since we dropped the distinction necessitating "proventesters"). And no, we don't have any blocker criteria around critpath.
Resurrecting the concept and adding criteria for it is an option, though.
Copying my comment from the test list:
Speaking as someone who "sells" this stuff, I think it'd be confusing for the Editions to offer different software (except where dictated by enabling the hardware). It'd be better to just say that we don't offer the Edition and instead suggest various spins for architectures where this comes up. Or, where we decide it's important enough, to make sure we use software that works across all relevant archs (or if possible to fix it when it doesn't work).
Just a reminder that we enter Beta Freeze at midnight UTC, so this decision is going to become urgent fairly soon.
As I noted above, technically all of our blocking install media are now covered since @stransky re-enabled armv7hl, but we are still missing builds on several other architectures which are likely to impact composes of those arches.
ppc/s390x builds are broken upstream - they force-enabled skia library which is not very well supported by s390/ppc. So don't expect ppc/s390 builds anytime soon.
@stransky I realize this isn't necessarily an optimum solution, but would it be possible to package and ship the Firefox LTS browser for those platforms that have problems supporting the latest-and-greatest?
Sure, that can be done but such package has to have a different name (firefox-esr for instance or so) and also needs to be shipped for all arches. For instance Debian also ships default Firefox and ESR variant.
I'm also not sure the Fedora Firefox team (Jan and Me) has capacity to create and maintain another firefox package. Would be great if someone else can do that.
Sure, that can be done but such package has to have a different name (firefox-esr for instance or so) and also needs to be shipped for all arches. For instance Debian also ships default Firefox and ESR variant. I'm also not sure the Fedora Firefox team (Jan and Me) has capacity to create and maintain another firefox package. Would be great if someone else can do that.
I can imagine someone from second-arch team or so may step in. We (Jan and Me) are keen to provide help/guidance here.
Let me add couple notes - FF (and TB) were requirements (BR and R) for tracker, but they were removed not so long ago meaning we should be able to live without FF - LTS Firefox (only) postpones the problem to the future, giving more time to fix the current (and future) problems with the code - there might be sufficient demand in the community for having LTS FF, but isn't that already solved by the icecat package? It builds for all arches - https://koji.fedoraproject.org/koji/buildinfo?buildID=892673
there might be sufficient demand in the community for having LTS FF, but isn't that already solved by the icecat package? It builds for all arches - https://koji.fedoraproject.org/koji/buildinfo?buildID=892673
IceCat package is based on ESR but includes bunch of extensions which makes browsing experience less smooth and regular users may find its behavior confusing and disturbing (broken webs, blocking pop-ups etc.). It may be also possible to ship IceCat package without any extra extension which would be roughly equivalent to Firefox ESR.
LTS Firefox (only) postpones the problem to the future, giving more time to fix the current (and future) problems with the code
ESR is also shipped in RHEL which means the second-arch fixes can be taken from there. And yes, it does mayor breakage only once per year.
Metadata Update from @maxamillion: - Issue tagged with: meeting
That statement doesn't line up in my head. You're pushing for a decision on our approach to the overall release, but putting an arbitrary deadline of Beta freeze on it. That's going to lead to us rushing based on available solutions today and not evaluate all possible scenarios, nor give us time to actually fix the problem.
Help me understand why this is urgent? Even if the compose is impacted we can fix that in comps for Beta while a solution is figured out for final. We do not need a final decision on this today.
I'm biased, but I don't see why Firefox is at all important for non-x86_64 architectures. These architectures are rarely used for desktop computers, and there are many other quality web browsers available in the distribution to choose from, e.g. Epiphany. If other architectures want Firefox, then the teams interested in those architectures ought to keep it working.
Our policy is for Beta to be basically finished, with only minor cleanups before release. Changing default browsers is (to me) in the realm of Change Proposal-level modifications which belong only in Rawhide at this point.
Help me understand why this is urgent? Even if the compose is impacted we can fix that in comps for Beta while a solution is figured out for final. We do not need a final decision on this today. Our policy is for Beta to be basically finished, with only minor cleanups before release. Changing default browsers is (to me) in the realm of Change Proposal-level modifications which belong only in Rawhide at this point.
Changing default browsers is a knee-jerk workaround for a BUG that needs to be fixed. Beta still allows bug fixes. By forcing a decision on changing a browser now, you're eliminating the possibility to fix bugs. I disagree with this interpretation.
Help me understand why this is urgent? Even if the compose is impacted we can fix that in comps for Beta while a solution is figured out for final. We do not need a final decision on this today. Our policy is for Beta to be basically finished, with only minor cleanups before release. Changing default browsers is (to me) in the realm of Change Proposal-level modifications which belong only in Rawhide at this point. Changing default browsers is a knee-jerk workaround for a BUG that needs to be fixed. Beta still allows bug fixes. By forcing a decision on changing a browser now, you're eliminating the possibility to fix bugs. I disagree with this interpretation.
I think I may not have clearly stated my intentions. My initial request was that FESCo declare it a blocker that Firefox doesn't build on all of the architectures that we support. As a compromise solution, I asked if it would be sufficient to ship the ESR version on some architectures where upstream is unable or unwilling to support them.
Since it doesn't look like I'll be able to make today's FESCo meeting, if this comes up for some kind of vote, please consider me a +1 towards any sort of proposal that's close to "Please add the developers to do their best to fix the bugs to allow this to build on all 'supported' platforms, but not to change the default browser."
@jsmith Does "change the default browser" apply to "switch to Firefox ESR" or only to "switch to Chromium/Epiphany/Elinks"?
I think it's important that when someone gets a Fedora Edition on any architecture that the software experience is basically the same (except where it's clearly a platform difference). I don't think a different browser (including Firefox ESR) meets this. If the architecture requires a different experience for some reason, we shouldn't target the Editions at it.
I might be convinced that Spins should be more relaxed about this, but I'm currently thinking that it's really the same. (Maybe Firefox ESR is the best choice for Xfce in any case, for example?)
So, I think this should be a blocker — but it might lead us to shuffling what's release-blocking. (Ideally, long before we get to beta, but here we are now.)
FESCo has the ability to block the release on any bug. I don't think we need to have hard guidelines around this to accomplish the goal you're driving for. Isn't the existing flexibility we have enough?
Mozilla tier-1 roughly match Fedora tier-1 - which means x86, x86_64 and 32-bit arm are tier-1 and are supposed to work unless there's some problem on our side (new gcc for instance and so on).
Fedora second arches (ppc, s390, aarch64) are tier-3 from mozilla POV which means we have to uplift changes and those may no be available for some time.
It seems that firefox is building on all arches now, so this is being closed.
Metadata Update from @jforbes: - Issue status updated to: Closed (was: Open)
Login to comment on this ticket.