Red Hat Enterprise Linux is a very influential yet deliberately conservative distro. They will be packaging Firefox 59 ESR when it releases in March 2018. Firefox 59 moves from nightly to beta on January 15, 2018, at which time the stable release of Rust will be 1.23 (having released nine days earlier, on January 4). Therefore, to build Firefox, RHEL will package Rust 1.23. Though there do exist other ways to obtain Rust on RHEL, it seems safe to assume that this will be the one and only version of Rust that RHEL will ship by default until 2019.
If we expect Rust to make traction in enterprise environments, we should assume that 1.23 is the version that they will target. This essentially turns 1.23 into a quasi-LTS whether we like it or not, and we might want to consider ensuring that “official” libraries don’t use any features that will keep them from compiling on 1.23.
But the most immediate concern is that Rust 1.23 is currently in nightly, and will move to beta on November 23. This is our last chance to have any say over the platform that prospective enterprise users will want to use, at least until 2019. Are there any features on the horizon that we really, really want to prioritize for this development cycle?
I’m the packager for the rust-toolset you linked, and we’re planning to use that for building Firefox ESR.
Please feel free to reach out to me directly (jistone@redhat.com) for Red Hat concerns, and we can make sure to pull in folks from the desktop teams/etc. as needed too.
Thanks for responding! Can you be more specific about Red Hat’s plans? I doubt that Mozilla will support Firefox 59 ESR with anything but 1.23. Having spoken to those in charge of maintaining the Rust toolchain for Firefox, they have said that it would be highly unusual for them to upgrade compilers for the lifetime of the ESR. This implies that Rust 1.23 will have to be available one way or the other; rolling releases won’t cut it. So does this imply that the rust-toolset package will remain on Rust 1.23 until 2019? Or is there some other solution in mind?
I don't want to get too specific, for fear making promises we can't keep. The main point is that rust-toolset is how we're planning to deliver rustc for now, so don't expect to see it in base RHEL yet.
Is that version actually decided yet? Last I heard (months ago) they were talking about freezing rustc earlier for the ESR branch, for the sake of all the more conservative distros. (e.g. to help Debian too)
This has implications for Mozilla in general, not just as it concerns RHEL. If Firefox ESR does completely freeze their Rust toolchain for that cycle, is anyone going to maintain that toolchain? Will it be a Rust ESR?
This is sort of what you asked to begin with, but my point is that it's not just about what Red Hat does. We've talked about broad ESR/LTS considerations in this forum before, but I regrettably never got around to drafting an RFC about this...
I do intend to keep rust-toolset rolling along. We won't be putting out every 6-week release, but we do want to update rust-toolset more frequently than we do for other SCLs. We also keep branches for our products though, so our Firefox buildroot could keep pulling an older rust-toolset if needed, and I can even patch updates.
But if Rust keeps its compatibility story, shouldn't it be fine for our Firefox ESR builds to use a newer toolchain than required? For instance, we don't try to match the exact same GCC that Mozilla uses either.
Ah, that's interesting to hear; I'm not a Mozilla person, just a Rust volunteer. When I spoke to Nathan Froyd, one of the Rust peers for Firefox, he didn't mention such a thing. But if using a release earlier than 1.23 is their plan then it means that we no longer have latitude to make any changes anyway, which sort of obviates most of this thread. Do you recall who told you this?
I don't know if it will be a Rust ESR; I haven't seen anyone talking about this which is why I've been trying to start a dialogue in the past few days.
I'd love to help out with that RFC. It's been on my mind a lot recently!
Interesting that you don't try to match the exact GCC version. Agreed that the compatibility story ought to protect the Firefox ESR. But firstly, I was under the impression that part of the reason for not continually upgrading the toolchain was to prevent new bugs from rearing their heads, and reducing the burden of testing M Rust compilers with N Firefoxes. And secondly, we're going to be doing some major architectural changes in 2018 (MIR borrowck, maybe Chalk) that have the capacity to both introduce new bugs and fix old soundness bugs, and the latter might break code (in particular some are worried about borrowed referent of a `&T` sometimes incorrectly allowed · Issue #38899 · rust-lang/rust · GitHub ). Breaking unsound code to fix it is allowed by the compatibility guarantee, and we'd certainly have a deprecation period if it looks like it would break a lot of code in practice, but there's a lot of unknowns here.
I think it was @brson. But I could be misremembering, or those plans may have changed, of course.
The rolling release thing will be an experiment for us -- a lot of unknowns, as you say, but I feel pretty safe that we can fall back if need be. None of these plans are set in stone. I do hope that all those coming changes don't rock the boat too hard though.
This conclusion is not correct. The contents of the buildroot, what is shipped to customers (as part of Red Hat Enterprise Linux or other offerings) and what is actually supported are largely separate matters. Something can be in the buildroot and unsupported (the Vala compiler, for example), or it can be supported and yet not be part of the base operating system buildroot (e.g., the compilers in Developer Toolset).
Do you recall who told you this?