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