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

[Andres Gomez]

Thanks Mark for bringing this thread to my attention by Ccing me ☺

I'll try to be brief and just comment inline.

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.

I agree.

> I would propose:
> 
>  - Patches are applied to proposed stable branch by automation when the
>    associated commit is pushed to master.  The existing commit message
>    annotations drive this process.  There must be zero ambiguity in the
>    annotations (eg which stable branches need the patch).
> 
>  - Committer is responsible for ensuring that the automation executed.
> 
>  - Failure-to-apply generates mail to release managers and committer.
>    The committer *should* have been able to test that the commit would
>    not apply before pushing the patch to master, and should get dinged
>    for this.
> 
>  - Failures to apply are resolved by committer, who must backport.  Each
>    backported commit references associated patch(es) on master in commit
>    message.  Backport is submitted by committer to release managers in
>    PR or email.
> 
>  - CI Automation immediately builds/tests the proposed stable branch
>    whenever it changes.  Release managers verify the results.
> 
>  - Any CI failures are resolved by force-pushing the series off of the
>    proposed branch.  Release manager communicates status to committer.
> 
> I think automation could be implemented to generate proposed stable
> branches on an arbitrary branch point in a local git repo.  Including
> this policy mechanism in our git tree would make the process
> transparent, verifiable, debuggable, and extensible.
> 
> Separately, I think we want to limit the ability of release manager to
> unilaterally change the stable build.  Release managers should not
> author any new commit in the stable branch that is not reviewed by
> another release manager, from a different company.


I agree in general terms with this.

As Juan has pointed, we have been doing some early CI in Igalia for the
nominated stable patches and we believe that moving forward to a tool
like GitLab will allow us to adopt most of the points listed here.


> > >  - Per team maintainer - each team has person (a few people) to check,
> > >    coordinate and remind people for high priority bugs and backports.
> 
> I've been doing this for Intel.  Developers are on the hook to fix their
> bugs, but you can't make them do it.  They have many pressures on them,
> and a maintainer can't make the call as to whether a rendering bug is
> more important than day-1 vulkan conformance, for example.
> 
> We could heighten the transparency of what is blocking the build by
> publicizing the authors of bisected blocking bugs to Phoronix, which
> might get things moving.


In any case, having a nominated person taking this role per team will
ease the coordination, I think. It could be a good idea.


> > Yes! I think this role is highly necessary, but not for the reasons
> > you outline here. My main issue thus far with the stable release
> > process has been that I don't appear to have any control over what
> > patches are included in a particular release. Reasons for rejection
> > have varied from "well, there will be another release in 2+ weeks" to
> > "this patch doesn't fit some arbitrary criterion".
> 
> If the patches are immediately merged to proposed stable branches, then
> they should be included by default.  It makes sense to have a standard
> window by which patches must be applied before a release.


I also think it makes sense to have a standard window.

Additionally, the criterion for inclusion can be just that the patch is
cleanly merged to the proposed stable branch but, so far, we have been
following these set of rules:
https://www.mesa3d.org/submittingpatches.html#criteria

What I mean is that we can just agree to allow anything that cleanly
applies to a proposed stable branch. I'm fine with it, so far this
agreement is explicit. Until now we have been trying to apply the rules
written in the link above, which still allow certain degree of
interpretation and, hence, conflicts inevitably arise.

-- 
Br,

Andres