On Wed, Mar 23, 2016 at 1:51 AM, Petr Cerny <pce...@suse.cz> wrote: > Henri Sivonen wrote: > Well... changes can be done, but have to be announced. Which is why this > thread is a Good Thing (TM).
That's why I started this thread. > By the way, from the picture referenced above I think that in the layout > engines part of the jungle you (as in Firefox/Gecko) sadly are the smaller > animal for quite some time now. That's why it's so important that we be able to leverage Rust to our advantage. >> But consider: Rust as a technology works the best on Linux. (IIRC, >> debugging info works better on Linux than on Mac and it's pretty >> clear that Linux and Mac are better matches for Rust development >> than Windows.) It's very messed up that the tech that works the best >> on Linux is the hardest to ship to users on Linux. > > > Saying "Linux is good, we can actually do things there, that are more > complicated elsewhere, but you are hindering our development" sound a > bit unfair. There is no contradiction between Rust working the best on Linux and being of the opinion that limiting ourselves to Rust features that were part of rustc when Debian stable last shipped is not okay. Clearly, there are distros that are don't have a policy issue with Firefox gaining a dependency on an actively-developed compiler. It's just that the need of a policy exception is what generates email. It's hard for me to tell if you represent a distro with which a rustc dependency will be a non-issue, since your comments run the gamut of implying your distro had a compiler bootstrapping policy stricter than Fedora's to saying that six weeks is viable. > The all-from-source, stable > interfaces and similar policies are there for a reason. Again, "stable" is a loaded word. Maintaining interface compatibility in the sense that stuff written to the old interface doesn't break on update is reasonable to want, but e.g. in the case of Debian that's not the criterion for getting to update a package (absent policy exception). rustc maintains compatibility in the sense that source code that compiled with some version (1.0 or later) of rustc continues to compile with later versions. As I understand Debian policy, even if upstream says that it's their explicit goal to maintain compatibility in the sense that new versions don't break stuff written for old versions, Debian assumes that upstream won't meet such a goal and instead only cherry-picking security fixes from the upstream is permitted (absent the sort of exception Chromium got). > Actually you could package Firefox for generic Linux by building your > own GCC and bundling all libraries (the whole GTK stack) into the > tarball/rpm - at some point replicating good portion of packages > installed on an average desktop system. These would be used by firefox > only and would (mostly) work (mostly) everywhere. You would actually be > doing exactly what we do for old code streams, only across multiple > distributions. You don't want to go there. Mozilla already ships binary tarballs compiled with a GCC version of Mozilla's choice. Those tarballs don't even need to include GTK+, because except for the changes between gtk2 and gtk3, GTK+ does a good job maintaining ABI compatibility. >>> 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 >> >> >> Not even Debian? > > > Your call, Mike... :) > > Genrally: it can be done Great! > Distributions should be fine with 6 weeks, if changes are announced with > reasonable time buffer. I'd expect it to make sense to update rustc every six weeks without specific notice. Maybe Firefox won't need a new rustc for every Firefox release, but considering the pace of development of rustc and the Rust standard library, I think it would make the most sense to plan with the assumption that both Firefox and rustc update every six weeks. > So 6 weeks > clearly is viable now. Great! > Having say rustc-X and rustc-X+4 for FF-Y and FF-Y+7 (which is the ESR > stepping), shouldn't be such a problem either It makes sense to assume that if Firefox Y depends on rustc X, Firefox Y+7 will depend on rustc X+7. > (although it does add > quite some work especially of you can't build rustc-X+4 with rustc-X > directly) But if you also ship rapid-release Firefox in addition to ESR, surely you'll need the rustc versions between X and X+7 for that. Since rustc continues to compile old programs, you could build Firefox Y.0.Z ESR with rustc X+Z, so you shouldn't need to keep an older rustc around for Firefox ESR while you are updating rustc to compile non-ESR Firefox. > Stable for LTS/enterprise means: doesn't change existing interfaces and > functionality. As in: f(x) is always be available, does f(x) and only > f(x). The main issue is whether you're allowed to add g(y) that does g(y) during the LTS cycle. > As far as I understand, rustc is not in this area yet when a > timeframe of the order of months/years is considered. Starting with Rust 1.0, you should expect new rustc releases not to break f(x) even if they add g(y). > The tendency to equate stability with out-of-date you mention usually > comes from people who haven't experienced servicing long-running > systems. AFAICT, equating "stable" with "out-of-date" (plus security-only cherry-picks) is factually correct when it comes to e.g. Debian (except the Chromium package). I'm not familiar with your distro's notion of stability. Again, I don't yet understand if your distro's policy is at odds with making Firefox depend on rustc. However, it seems to me that Debian's is and what Sylvestre (suggested Firefox maintaining compilablility with the rustc that was current when Debian stable shipped) and Mike (not seeing rustc updating every six weeks happening) have said in this thread seem to support that notion. I'd like Debian to grant rustc the kind of policy exception Chromium got. I don't yet understand if the situation is already OK with your distro without a policy exception. > I'm not sure you are fully aware of the main reason behind ESR. It is mostly > testing internal enterprise web applications and add-ons, which often takes > over a month. For exactly this reason there is a 3 months overlap (or even > 4.5 if one counted -beta) and some 9 months of support. I'm well aware that the ESR schedule is based on that idea of intranet compatibility testing. It's not clear to me if what proportion of ESR recipients actually perform the testing as intended. > This actually also suggests that it is better to leave more fundamental > changes in functionality the releases shortly after ESR release It seems like a good time to talk about Rust now that there is no risk of anyone thinking that Rust code would be going into 45 ESR. -- Henri Sivonen hsivo...@hsivonen.fi https://hsivonen.fi/ _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
