Thanks for starting this discussion and I really want to thank you for offering Bodhi to handle the Rawhide. It would be really sad I some other system was used for Rawhide then for stable versions.

Dne 9.3.2018 v 10:20 Pierre-Yves Chibon napsal(a):

On Thu, Mar 08, 2018 at 01:00:32PM -0500, Randy Barlow wrote:

I would like to kick off a general discussion about how we might gate
packages in Rawhide. I think it would be nice to get something in place
for the Fedora 29 timeframe.

I was waiting to have some more time to work on it to kick off that discussion.
This is cool as it means there are more people interested in having this :)

As one of the Bodhi contributors, I am inclined to suggest that we could
use Bodhi on Rawhide, similar to how we use it for our stable/branched
releases, with more relaxed rules (perhaps 1 day in testing or something
simple).

It may be possible to automate the process a bit to make it less heavy
for developers, though there is some complication for multi-package
updates (more on that in a bit). For simple package updates, we may be
able to detect new commits on dist-git, and react to those by
automatically starting a Koji build, and automatically filing a Bodhi
update when that build is complete. I think that would be pretty nice,
and pingou created a PoC[0] to do this about a year ago.

Multi-package updates won't be so easy though. It's not uncommon for us
to need to update packages together, and the above workflow would be
problematic since it would result in updates with single packages in
them rather than updates with multiple packages. Of course, buildroot
overrides would be a problem too, since multi-package updates often
depend on each other at build time too.

We could create some way for packagers to indicate that a commit (or
possibly even a whole repo) is not intended to be "autobuilt/updated".
If the packager indicates this then their builds would go into a
rawhide-pending (similar to what we do for f27 today). Once they have
all their builds (and buildroot overrides) the way they want them, they
can create the update.

Another idea that was tossed around in some chats I had with people
about this involved a system for packagers to use to create Koji side
tags. Bodhi manages BuildRoot Overrides today (with expirations), so
perhaps Bodhi could be expanded to also manage Koji side tags (also with
expirations). I can't remember all the details about this approach or
why it was suggested over the former approach, but I wanted to list it
to invite others to chew on it and see if it could work.

If you have other suggestions on how we might gate packages in Rawhide
that are wildly different than the above, please feel free to share!

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 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).

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.

For this to work we could need:
- one new koji tag on rawhide (easy)
- support for side-tags in bodhi
- likely improving the side-tags generation in koji
- a few services, likely fedmsg-based, to link the different services (tests
  results to src.fp.o/bodhi, migrate package to the next koji tag when test
  results is published, when a waiver is submitted push the package to the next
  koji tag...)

The idea to automatically build upon commit is neat and something we can look
into, but I think it can be approached separately from gating rawhide, one
doesn't require the other.

I really don't like the idea of building something based on commit. Each commit should be atomic and meaningful. If you will build based on commit, that could motivate maintainers to put more unrelated changes into single commit. And of course, you should be speaking rather about "build unpon push", since push can contain more commits.

V.

Speaking of both changes in one go might confuse things a little.


Pierre

_______________________________________________
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-leave@lists.fedoraproject.org