On 01/23/2018 12:14 PM, Aleksa Sarai wrote:> You mention that Go does a lot of testing to avoid regressions, *so does
the Rust community*. They do a "crater run" (rebuild and unit-test of all crates on crates.io) on a regular cadence during development, when large features are being considered for merging, and for gating releases.
They test on x86_64/x86 *only*. Is openSUSE x86_64/x86 only?
If they find an issue they either fix it in the compiler (if it's a regression) or they go to the project itself and submit a patch (if it's actually a bug in the project). This is one of the things that is mentioned in literally every talk about the Rust development process.
Cool. Can you fix Rust on mips* and powerc32, please? I have been trying to bootstrap it on these targets on and off for several months now. Rust upstream is super fast and busy fixing the compiler on non-x86 platforms. NOT.
Rust upstream lives in a universe where they think that distributions are an outdated concept. This is why they are shipping their own package manager and consider such breaking changes in minor releases acceptable.
I agree that their attitude toward distributions is a problem (for us obviously, but also for users IMO). But this is also an attitude that is shared by a very large number of languages and projects these days.
The other projects aren't trying to mess with core packages, Rust does. If NodeJS or Go blow up in your face, you aren't breaking half your distribution. That's a HUGE difference.
I cannot help but think that the root cause of this problem is that we have not done a good job (as distribution developers in general) of convincing people of the benefits of having a distribution that has a global view of packaging of a system.
I'm pretty sure we have done an excellent job at that. Otherwise we wouldn't have customers who are giving us money for that. You are making the mistake that you assume that people running bleeding edge software have a large relevance for what we do. They don't.
I think us trying to ship projects that use Rust Nightly would be absolute madness (I also think it's mad to depend on Rust Nightly features for a "stable" project, but that's a separate topic). However, we can avoid the nightly problem by not shipping things that depend on nightly (neither Firefox nor the library that spawned this discussion depend on Nightly).
I consider this absolute madness: glaubitz@suse-laptop:~> osc whatdependson openSUSE:Factory librsvg standard x86_64 | wc -l 314 glaubitz@suse-laptop:~> And this doesn't even include transitive dependencies.
I don't think you always need the latest version of Go for updating Docker. I have worked with both codebases myself and never ran into this issue.
Not always, but there have been cases (we're talking ~2 years ago) where a Go upgrade has broken Docker in subtle ways. This was before runc was a separate project, and they were still using "os/exec" for parts of container setup (which obviously proved to be a horrible idea, and now we have the whole nsexec magic that I'm tasked with maintaining upstream).
The difference is that Go isn't trying to push itself as a systems programming language trying to replace core components of a Linux distribution. If Go breaks, it doesn't potentially affect the whole distribution. In the case of Rust when replacing something as librsvg or coreutils with a Rust version, it does. Adrian -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org