On Wed, 29 Nov 2023 at 16:49, Daniel P. Berrangé <berra...@redhat.com> wrote: > > On Wed, Nov 29, 2023 at 08:50:06AM -0700, Warner Losh wrote: > > I'd honestly optimize for 'frequent merges of smaller things' rather than > > 'infrequent merges of larger things'. The latter has caused most of the > > issues for me. It's harder to contribute because the overhead of doing so > > is so large you want to batch everything. Let's not optimize for that > > workaround for the high-friction submission process we have now. If there's > > always smaller bits of work going in all the time, you'll find few commit > > races... though the CI pipeline is rather large, so having a ci-staging > > branch to land the MRs to that have completed CI, but not CI on the tip, > > might not be bad... but the resolution of conflicts can be tricky, though > > infrequent, so if a ci-staging branch bounces, all MRs would need to be > > manually requeued after humans look at why and think through who needs to > > talk to whom, or if it's just a 'other things landed before you could get > > yours in and it's not the ci-staging being full of other people's commits > > that is at fault. > > I agree. Right now we tend to have fairly large pull requests, because > people are concious of each pull request consuming non-trivial resources > from the release maintainer. If this new MR based approach reduces the > load on the release maintainer, then sending frequent small pull requests > is almost certainly going to be better.
FWIW, in the current system also I would recommend submitting smaller pullrequests rather than large ones. For me when I'm doing release handling, pushing pullreqs through the process is not that difficult. The problems come when there are test failures that need to be tracked down, and those are more likely to be problematic if they're in the middle of a huge pullreq than if they're in a smaller one. Plus waiting means things don't get into the tree as soon, which just extends the timelines on things. thanks -- PMM
