Re: [gentoo-dev] Add rust eclass to support multi-target compilation
Hi! On Mon, 30 Jul 2018 17:00:20 +0200 gibix wrote: > Hello, > > I opened a PR here: https://github.com/gentoo/gentoo/pull/9388 > > Here a copy of the message: > > # add support for rust multi-target > > - add rust.eclass (with rust-utils.class) to support rust multi-target with > multibuild > - modify cargo.class to support rust multi-target > - change dev-lang/rust slot system > > This will allows projects like rustfmt, clippy, bindgen that need runtime > linking with the proper rust version to work correctly. Beyond this while > rust is getting older as project we will see more projects that will > require a specific rust version for compilation. > > This PR replaces the need for rustup in gentoo for toolchain handling and > components. > > requires: > - [features in > > cargo-ebuild](https://github.com/cardoe/cargo-ebuild/pull/14/commits/1aefd302f9430c0b628923da23e2a8d74b83d1ec) > - [binaries support into > eselect-rust](https://github.com/jauhien/eselect-rust/pull/4) > > see first discussion on > [gentoo-rust](https://github.com/gentoo/gentoo-rust/pull/362) If you are submitting code to the main tree, please submit all requirements to the tree first. Your PR brokes tree: https://github.com/gentoo/gentoo/pull/9388#issuecomment-408914903 Please fix these issues as well, for both QA and CI checks. (These problems may be a result of ยง1 (not yet submitted changes to the tree). It would be easier if your will split your improvements into series of atomic changes and submit them individually for review. Best regards, Andrew Savchenko pgpyqcZzV6va0.pgp Description: PGP signature
[gentoo-dev] Add rust eclass to support multi-target compilation
Hello, I opened a PR here: https://github.com/gentoo/gentoo/pull/9388 Here a copy of the message: # add support for rust multi-target - add rust.eclass (with rust-utils.class) to support rust multi-target with multibuild - modify cargo.class to support rust multi-target - change dev-lang/rust slot system This will allows projects like rustfmt, clippy, bindgen that need runtime linking with the proper rust version to work correctly. Beyond this while rust is getting older as project we will see more projects that will require a specific rust version for compilation. This PR replaces the need for rustup in gentoo for toolchain handling and components. requires: - [features in cargo-ebuild](https://github.com/cardoe/cargo-ebuild/pull/14/commits/1aefd302f9430c0b628923da23e2a8d74b83d1ec) - [binaries support into eselect-rust](https://github.com/jauhien/eselect-rust/pull/4) see first discussion on [gentoo-rust](https://github.com/gentoo/gentoo-rust/pull/362) signature.asc Description: PGP signature
Re: [gentoo-dev] rfc: [QA] Ban policy introduction
On Mon, Jul 30, 2018 at 8:52 AM Guilherme Amadio wrote: > If you introduce penalties for breaking prefix as well, I'm afraid many > people will be unnecessarily penalized. I think that such penalties are > counter productive in most cases. If someone is really being careless it > might make sense to get some warning and lose commit access temporarily. > If someone made a simple mistake that can be easily fixed, like version > bumping a package that starts to fail in some corner case, then > punishment doesn't make much sense. > The proposed policy already mentions that people will only be punished after two warnings. This seems enough for me -- if people keep breaking stuff despite warnings, a little penalty is probably a good thing. The proposed policy already goes out of its way to require two warnings for "independent" breakage, but it's not entirely clear what independent means here. If you commit three breakages that are technically unrelated on the same day, then you probably shouldn't be banned immediately. So I would suggest also making clear that the warnings should be sent at least a few days apart and that an initial penalty cannot happen until a few days apart the second warning. That said, I agree with those who are saying that breaking things should be obvious, things like ignoring repoman and/or other CI messaging. If the breakage is non-obvious and hard to spot locally, then we should instead invest in tooling to make it more obvious. By "ignoring" here I do mean that there needs to be a reasonable timeout -- sometimes if I commit a change and get a CI alert after a few hours, it might be tricky due to work/family/whatever concerns to fix it within, say, 24 hours. Regards, Dirkjan
