[Mesa-dev] [RFC] Mesa 17.3.x release problems and process improvements

[Dylan Baker]

Quoting Mark Janes (2018-03-12 12:40:47)
> Dylan Baker <dylan at pnwbakers.com> writes:
> 
> > Quoting Emil Velikov (2018-03-12 08:38:31)
> >> On 12 March 2018 at 11:31, Juan A. Suarez Romero <jasuarez at igalia.com> wrote:
> >> > On Fri, 2018-03-09 at 12:12 -0800, Mark Janes wrote:
> >> >> Ilia Mirkin <imirkin at alum.mit.edu> writes:
> >> >>
> >> >> > On Tue, Mar 6, 2018 at 2:34 PM, Emil Velikov <emil.l.velikov at 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.
> 

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
2. CI starts
3. you push patches
4. My CI fails
5. I force-push

Now both of our patches are removed, even though yours haven't gone through CI
at all. 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 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.

Dylan
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: signature
URL: <https://lists.freedesktop.org/archives/mesa-dev/attachments/20180312/b7392da5/attachment.sig>