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. Dylan
signature.asc
Description: signature
_______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
