Dylan Baker <dy...@pnwbakers.com> writes: > Quoting Mark Janes (2018-03-12 12:40:47) >> Handling a screw-up could be done by maintainers by force-pushing the >> commits off the WIP branch, and adding some annotations that prevent the >> broken commit from being re-applied to WIP by automation. >> > > That sounds like introducing a lot of developer headaches, the kind that make > people not want to use the system. Take this scenario: > > 1. I push patches
In this case the person is a developer, not a release manager > 2. CI starts > 3. you push patches I'll call this person "developer 2" below. > 4. My CI fails At this point, developer 1 needs feedback that their patch nearly created a problem for many end-users. Frankly, it's unacceptable for developers to annotate a commit for the stable branches unless they are confident that it is a *safe and necessary* fix for end-users. We have almost zero verification between the developer and millions of users. > 5. I force-push A release manager would have to resolve the failure manually, not developer 1. Developers can't force-push anything in my proposal. > Now both of our patches are removed, even though yours haven't gone through CI > at all. Release manager would manually drop patches from developer 1, and leave the patches from developer 2. CI would re-test patches from developer 2. > And if our tool isn't smart enough it will block your patches as well. > In fact, I can't think of a way to make force pushes on a branch that > multiple people work on *not* have race conditions. I agree that there is a race condition here. Right now our race condition covers a weeks long window between the time a developer CC's stable, and when the release manager starts applying patches. With an automated implementation, the window narrows to a day or so. > I think that we should either: > 1. Use gitlab and have CI run on PRs as well as on merged code. Either the PR > will be red and gitlab can block the merge, or it will be green. It should > be > possible to have gitlab block code that cannot be cleanly merged. > 2. Use merges and reverts. My 2 cents: choosing a specific git service is a step in the wrong direction for mesa. I agree that providing a branch to a release manager may be preferable to email, in the cases where a developer has to backport patches. _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev