Dylan Baker <dy...@pnwbakers.com> writes: > Quoting Emil Velikov (2018-03-12 08:38:31) >> On 12 March 2018 at 11:31, Juan A. Suarez Romero <jasua...@igalia.com> wrote: >> > On Fri, 2018-03-09 at 12:12 -0800, Mark Janes wrote: >> >> Ilia Mirkin <imir...@alum.mit.edu> writes: >> >> >> >> > On Tue, Mar 6, 2018 at 2:34 PM, Emil Velikov <emil.l.veli...@gmail.com> >> >> > wrote: >> >> > > So while others explore ways of improving the testing, let me propose >> >> > > a few ideas for improving the actual releasing process. >> >> > > >> >> > > >> >> > > - Making the current state always visible - have a web page, git >> >> > > branch and other ways for people to see which patches are picked, >> >> > > require backports, etc. >> >> > >> >> > Yes please! A git branch that's available (and force-pushed freely) >> >> > before the "you're screwed" announcement is going to help clear a lot >> >> > of things up. >> >> >> >> I agree that early information is good. I don't agree that anyone >> >> should force push. Release branches need to be protected. Proposed >> >> release branches should only accept patches that have already been >> >> vetted by the process on mesa master. >> >> >> Agreed - release branches should not be force-pushed. We can use >> "wip/" ones instead. > > I also strongly agree with this, force pushes to live branches are > *bad* (force pushing a pull request of a features branch are perfectly > fine). I would much rather have reverts than force pushes. If we're > going to automate this in such way that we think we need force pushes > I'd much rather use merges (only for stable), so that we can simply > revert the merge commit. > > Or, as other have suggested, not allowing the proposed patches to be > pushed until CI has come back green would be even better. I've used > this approach in several github based projects and it works very well > for keeping the branch in question in good shape.
The patches need to be in a branch for any CI to test them. A WIP branch seems like a good thing for CI to poll. If CI fails at this point, then it means the developer messed up. No one should add a fixes/cc tag to a commit unless they have some confidence that it will work on top of the WIP branch (by *testing* it). 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. > Dylan _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev