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

[Mark Janes]

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.

> Dylan