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. 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? 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. Pierre
Attachment:
signature.asc
Description: PGP signature
_______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
