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

[Mark Janes]

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.