On 03/08/2018 10:00 AM, Randy Barlow wrote:
Greetings fellow Fedorans!
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 hoping we could come up with a more detailed proposal for the
community at the upcoming Infrastructure hackfest, but sure we could
start the discussion now.
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).
I don't think a testing will be of help here. Who would run with it
enabled? I'm much prefer we just use the gating to run automated tests
and get the update out as quickly as we can after that.
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.
This has nice appeal for simple standalone updates...
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.
having to file overrides would be a pretty big drag for people like the
KDE/Gnome teams... but I suppose they do it somehow in stable updates now.
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.
This approach has the advantage of not needing buildroot overrides, you
just build all the things into the side tag in whatever order needed.
The downside is that these would take koji cycles to keep doing newrepos
for.
I was org not in favor of using bodhi, but it was noted that this is the
one place we have now for test results and gating, so I kind of think we
do need to use it now. That allows us to reuse it and waverdb, etc.
I really don't want to slow rawhide down or put barriers in place for
maintainers, so I think we need to make things as painless as we can.
kevin