Re: Gating packages in Rawhide

[Vít Ondruch <vondruch@xxxxxxxxxx>]

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@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx

Attachment: signature.asc
Description: OpenPGP digital signature

_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx