Dne 9.3.2018 v 11:24 Pierre-Yves Chibon napsal(a): > On Fri, Mar 09, 2018 at 10:52:27AM +0100, Vít Ondruch wrote: >> I had a different idea in mind, basically try to keep the experience as >> close as >> what it is now. >> for single package: >> - packager commit >> - packager build >> - build is tagged into a specfic koji tag >> - test are run on this tag >> -> results go to src.fp.o >> - if tests pass >> - package is moved to another koji tag >> - package is signed >> - package is pushed to rawhide >> - if tests do not pass >> - do nothing >> - if the user submits a waiver >> - move the package to the next koji tag for signing it >> If a packager does not want to run the tests, we could have a fedpkg build >> --noci that would directly build the package in the koji tag used for >> signing >> the package (useful for mass-rebuild for example) >> >> for multi-package: >> - packager requests a new side-tag (I'd propose via bodhi) >> - packager build all the different packages in that side-tag >> - packager asks for the side tag to be merged >> - tests are run on all these packages >> -> results go to src.fp.o >> --> We probably want to also report them on the bodhi request to merge >> the >> tag as otherwise the packager will have to go through all the >> package to >> find the one(s) that failed >> - if tests pass >> -> cf above >> >> I more or less like your proposal. But I have to highlight one danger of >> sidetags and that is you have use the "--target" option. If you forget it >> by accident (and it is quite easy to forget), you will unintentionally >> mess the main Rawhide repository. From this POV is much safer to use build > You wouldn't mess the main repo as it would not have been built against the > new > version of the library you updated and are trying to rebuild against.
It depends what you are building. If are building package foo with soname bump and its dependencies, the if you build the foo by accident into the official tag, then you are in troubles. And for that dependencies, it depends. If you bum some dependency in the middle of the chain, to be compatible with the new soname, but it requires some other runtime dependencies, and you build it in the official tag instread of the side tag, you are in trouble again. > So for > that package there is no change compared to what was already in rawhide. And > for > the side-tag when trying to merge it changes are that the tests would fail no? > >> overrides. Also, using buildroot overrides is probably more infrastructure >> resources friendly. BTW the buildroot overrides could be submitted >> automatically by "fedpkg build", with possible opt-in/out (depends what >> will qualify to be better default). > Buildroot override means we gate the packages for an unknown time. The > buildroot > override means: adding to the buildroot something that isn't already there. So > how would we know when to wait (depending libraries need a rebuild) and when > not > to wait (single-package update)? > If we always push, we end up with the current rawhide situation no? The buildroot override can be sumbitted or expired. You can't do that in Rawhide now. So there are two possibilities: 1) We automatically submit override, but it could be expired based on testing. 2) If more packages are needed to build, the override can be submitted manually. > If we default to wait, we end up with what we have currently in stable > releases > and are changing quite our packaging workflow. > I'm not saying it's not an option, just that it needs to be made clear to > everyone. > >> Also, using side-tags without appropriate branches is wasted opportunity. >> If I could have "master-mysidetag" branch, I would use to build my >> packages and side-tag merge would mean to merge dist-git as well as the >> repository, it would be even more meaningful. > This seems a lot of work without necessary a lot of gain tbh. It was just me dreaming :) I realize it is a lot of work so this would be just NTH. V. > > > Pierre > > > _______________________________________________ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org
signature.asc
Description: OpenPGP digital signature
_______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
