On Thu, Mar 17, 2016 at 04:59:29PM -0700, bander...@mozilla.com wrote:
> Hi,
> 
> This is a matter that concerns the Rust team a lot. From the Rust side
> we want to make it possible for Debian and Fedora (as a proxy for all
> distros) to be able to bootstrap off of their own rustc's and keep up
> with the Rust release process.
> 
> We have a [good idea][1] about how to accomplish that part, though I
> haven't followed through on the [implementation][2]. In particular, as
> noted in this thread, you can't bootstrap off of either the current
> version of Rust or the previous. This is actually a problem that could
> be fixed in about one release cycle. There's little excuse not to do it
> yesterday, though some on the team have lingering worry about having
> to wait 6 weeks to complete unstable language changes.
> 
> We have less understanding of what it will take to get the major
> distros to a) actually deploy rust in a stable release, b) keep rust updated
> every 6 weeks.

I don't see b) happening.

> > Do we have a plan being executed to make sure that when Gecko
> components written in Rust ship on the release channel in
> Mozilla-produced builds the also ship in the Firefox packages of
> various Linux distributions?
> 
> On the Rust side we have a plan to unblock the distros ability to
> package Rust [1]. As far as getting Rust into distros, we continue to
> go through cycles of finding blockers on the Rust side, fixing them,
> and then discovering what else is blocking the distros Unfortunately,
> after the initial push in the above threads, this has been on the
> backburner. I intend to push on it again next quarter.
> 
> > When is rustc expected to reach that level of bootstrapping predictability?
> 
> It should be feasible to make this change soon, but we'll need to
> discuss at the next core team meeting. I'll get back to you on that.
> 
> > I think it's unacceptable to limit our ability to leverage Rust in
> Gecko by forgoing the ability to co-evolve Rust and Gecko at a rapid
> pace.
> 
> Even after hurdles of getting stable rustc into distros is solved I
> think this is one of the most difficult issues. In particular, Firefox
> needs to be buildable on the *stable* Rust compiler in order for
> distros to build it. Rust's nightly compiler contains unstable
> features that we don't want used generally; it's the stable compiler
> that we promote and want distros to package. If Firefox requires
> nightly unstable features, then distros will be forced to package
> nightly Rust. If those distros users learn to expect that the nightly
> compiler is available then that could severely compromise Rust's
> strategy for evolving the language.
> 
> Note that there's a big diference between Firefox needing to
> continually update to a bleeding edge Rust, and Firefox using
> *unstable* Rust features. It's fine to update to a new Rust compiler
> every few weeks, even Rust nightlies, as long as Firefox doesn't turn
> on unstable features (which must be done explicitly).
> 
> > I think we must not allow ourselves to wait for a Debian or Ubuntu LTS
> cycle before Rust improvements can be used in Gecko.
> 
> > I agree with Brian Smith's sentiment at
> https://internals.rust-lang.org/t/perfecting-rust-packaging/2623/67
> 
> I agree that Rust being stuck on the distro LTS cycle is impracticle
> for real software.
> 
> If Rust produces 'universal' debs and rpms as suggested by @briansmith
> that would be enough for distro *users* to build Firefox, but it's not
> sufficient for the distro's themselves to keep their Firefox's up to
> date. I think Rust should do this but it isn't clear that it solves a
> critical problem.
> 
> Firefox's release model also has this tension with distros, and even
> LTS distros *do* update Firefox, right? Is there any chance Rust can
> recieve updates like Firefox?

LTS distros do update Firefox because there is no way they can support
security updates on older releases (I've done it with 3.5 long enough to
know it's not tractable). But they do it once a year (at every ESR bump),
not every 6 weeks.

Mike
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Reply via email to