On 6 June 2016 at 05:34, rindeal <[email protected]> wrote: > efore merging to master they do a rebase+force push, > let the CI check it, and if it passes they're allowed to merge it. No > cherry-picking involved. Master is then always clean and happy. I'm > not sure how well it scales, but for the 100-150 commits/day the tree > sees currently, it should be doable.
And then somebody else merges in the interval between you submitting it, the CI check starting, and the CI check approving it (keeping in mind the CI run is ~10 minutes long), but what merged breaks your commit and the CI didn't see it? Now what? Or does everyone have to form an orderly queue where they wait for the CI ? That' maxes out at 144 pushes / day. This is not the kernel where we have a clean release cycle we can target and sit on patch series for a week or more while we polish it, and we don't have an avalanche of "this is good, it lands in this release". This is pretty much one of the big limitations of "Shared push" patterns in that their workflow and "unified branching" workflows contradict each other in lots of ways. -- Kent KENTNL - https://metacpan.org/author/KENTNL
