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

[Dylan Baker]

Quoting Mark Janes (2018-03-12 14:59:29)
> Dylan Baker <dylan at 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.

I think that letting the release manager take branches would be superior, that
would mean that only the release manager should be doing pushes at that point
and some of the pain of force pushes is removed (the pain of tracking such a
branch isn't, but the pain of pushing is).

I bring up gitlab because the plan seems to be (shhhhh) that fdo is migrating to
gitlab as a whole, even if individual projects are free to continue using
mailing lists instead of pull requests.

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/144eed16/attachment.sig>