Hello again! There's been a lot of discussion on this thread, and some useful feedback. Thanks! I would like to make a clearer proposal about how gating in Rawhide would work: Multi-package update workflow ============================= When a packager wants to update multiple interdependent packages (such as a Gnome or KDE update), they will request a new side tag from Bodhi (we can make a fedpkg feature for ease), and then they will use fedpkg build --target=my_side_tag for each package they want to include in the same update. The packager could also use chain building to do this if preferred. When the packager has finished the builds they intend to group together, they will request the side tag to be merged via Bodhi/fedpkg. This will create a Bodhi update and will trigger tests to run on the set of packages included in the side tag. If the tests pass, Bodhi will merge the side tag into Rawhide, and the packager's work is done. If they fail, the packager will need to take action to get them to pass, or submit a waiver to waiverdb to ignore them. Once the side tag is merged, the update will be marked stable automatically by Bodhi (no need for karma or time in testing) and will be tagged into the rawhide tag. Single package update workflow ============================== If a packager wants to update a single package, they will use fedpkg build, without specifying a side tag. fedpkg can see that the user did not specify a side tag, so it will go ahead and prompt the user for update details and create an update (or we could make this opt-in, either way). Once the Bodhi update exists, tests will run. If the tests pass, Bodhi will automatically mark the update for stable and the packager's work is done. If the tests fail, the packager will need to either fix the problem or waive the update. Benefits ======== * We increase the quality of packages in Rawhide through automated testing. * By giving Bodhi the ability to manage side tags, we can also give side tags to packagers for stable releases. This will allow packagers to chain build for stable releases in addition to rawhide, which is not possible today. * The workflow isn't so different from what we have today. Single package updates are nearly the same, and multi-package updates often manually request side tags from releng. Buildroot overrides =================== If Bodhi can provide side tags to packagers, the use case for buildroot overrides becomes diminished. I am not able to immediately think of a purpose for them that would remain, but it would be bold to say they would have no purpose with this design. If we go with the above design, we should monitor buildroot override usage and remove it if it is unused. We may even make it an admin-only feature (you would request it from releng). Thanks to pingou for creating the nice flowcharts for us.
Attachment:
signature.asc
Description: OpenPGP digital signature
_______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
