On Wed, 2025-07-30 at 13:53 -0400, Stephen Gallagher wrote: > On Wed, Jul 30, 2025 at 1:01 PM Kevin Fenzi <ke...@scrye.com> wrote: > > > > On Wed, Jul 30, 2025 at 03:44:05PM +0200, Miro Hrončok wrote: > > > > > > Let's have draft builds like in CentOS Stream? > > > > > > A pull request is scratch built anyway. Let it build as draft build and > > > when > > > the PR is merged, promote the draft build to a real one (in a side tag if > > > needed). > > > > Are there any docs or description of the full flow there? > > Define "the full flow" please? The basics are: > > * The merge request is submitted and a request for draft build testing > is made (today while it's in "Beta", this is a Gitlab MR label, in the > near future this will just become the default for all MRs) > * The CI pipeline starts to run, generating a draft build in CS Koji > (and internally in RHEL's Koji infrastructure). > * The completed draft builds are used to run a series of acceptance > tests. If all of them pass, the pipeline grants approval and the > packager can merge. (If the pipeline doesn't grant approval, someone > other than the packager must do so if they need to override the > decision). > * The package hits the merge button and another pipeline (called a > "merge train") begins. This one runs a few final sanity checks (like > verifying that we haven't transitioned from "development" to > "stabilization" phase and requires more stringent approvals) and then > "promotes" the CS and RHEL draft builds to official ones. Then the > merge completes. > > > I mean, there's a bunch of corner cases... like you have 5 PR's (so I > > guess you merge one and the rest make new draft builds and the next one, > > etc). > > > > But yeah, we could figure out a setup there... > > > > That's an extreme corner case for packaging, since it's quite rare to > have two people working on independent merge requests to update a > package. The solution there is to have the git forge require only > fast-forward merges, which means that once one is merged, the others > will be non-mergeable until they rebase (which will create a new draft > build). In the extremely unlikely event that there's more than one > waiting in the wings, the merge of the first one should be a clear > signal that the remainder should be coordinated so as not to generate > too many useless draft builds. > > Such multiple PRs are far more common on upstream packages. So for us > (Fedora), the most likely places to have to deal with that would be > things like SRPM macros, where the package IS the upstream. We may > want to have a separate policy for those. It's an interesting > question. But those are definitely the exception, rather than the > common case.
I bet you can guess what I'm going to say. But I'm going to say it anyway. ;) Any workflow like this needs to solve the problem of interdependent changes. This is much more important for Fedora and ELN than anyone else, because we're where all the interface changes happen. If the system doesn't handle this scenario sensibly: * Submit a PR to libfoo that bumps its soname * Submit a PR to bar-app to rebuild it against the new libfoo soname * ??? * Profit then it cannot be viable for Fedora. Broadly, what happens in ??? - assuming bar-app is the only user of libfoo - needs to be "the PRs are cleared for merge but *required* to land together and produce a pair of packages that will be guaranteed to land together or not at all". -- Adam Williamson (he/him/his) Fedora QA Fedora Chat: @adamwill:fedora.im | Mastodon: @ad...@fosstodon.org https://www.happyassassin.net -- _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
