Thanks everyone for your comments. If we were to run linux32 tests in whole on mozilla-central only that would result in about half of the load we see from linux32 today and about 1 backfill a week (given that most unique linux32 regressions result in test disabling). That alone would be a good savings of time, money, and reduction of intermittents.
I would like to see what others think about keeping the platform supported on trunk vs letting it ride the trains to beta where it would live until near the end of 2020. I assume a discussion about what unique features and code will help determine what level of support we want for tests/builds of linux32. On Wed, Apr 10, 2019 at 12:53 PM Bobby Holley <bobbyhol...@gmail.com> wrote: > I'd like to refocus this thread a bit around Jed's question, because it > gets to the core of the issue. > > The proposal argues that test results for linux32 closely track those for > linux64, and that this duplication is expensive. If that's the only > problem, we could solve it by keeping linux32 as a tier-1 platform, but > just running the tests much less frequently. This would require > occasionally backfilling jobs when something does break, but that should be > rare. > > There is a separate question of whether it is expensive to _engineer_ for > linux32, and whether we should drop support on those grounds (a la Windows > XP and non-SSE2). So far, the only linux32-specific engineering cost that > has been raised is linux32-specific sandboxing code. Is this a significant > maintenance burden? Are there other large areas of the code that are > linux32-specific? > > > > On Mon, Apr 8, 2019 at 4:20 PM Jed Davis <j...@mozilla.com> wrote: > > > jma...@mozilla.com writes: > > > > > As our next ESR is upcoming, I would like to turn off linux32 on > > > Firefox 69 and let it ride the trains and stay on 68 ESR. This will > > > allow builds/tests to be supported with security updates into 2021. > > > > Does this mean that Linux on 32-bit x86 is being demoted to Tier 3, like > > (non-Android) Linux on other uncommon architectures? Have we identified > > a maintainer to take responsibility for testing and working with us to > > fix regressions? I don't see how it can remain Tier 1 without CI > coverage. > > > > Also, will it still be possible to explicitly request linux32 on Try > > runs? Our cross-building story is not good, and being able to use Try > > for this helpful for avoiding regressions and testing changes to > > arch-dependent code. > > > > For context, I'm the module owner for Linux sandboxing, and we have to > > deal with low-level details of the system call ABI, and as a result > > there is nontrivial code used only for linux32 that I'm responsible for. > > > > --Jed > > _______________________________________________ > > 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
