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

[Juan A. Suarez Romero]

On Wed, 2018-04-04 at 11:27 -0700, Mark Janes wrote:
> "Juan A. Suarez Romero" <jasuarez at igalia.com> writes:
> 
> > On Wed, 2018-04-04 at 10:07 -0700, Mark Janes wrote:
> > > Emil Velikov <emil.l.velikov at gmail.com> writes:
> > > > In detail:
> > > >  * make the patch queue, release date and blockers accessible at any
> > > >    point in time:
> > > >     * queued patches can be accessed, via a branch - say wip/17.3,
> > > >       wip/18.0, wip/18.1, etc. The branch _will be_ rebased, although
> > > >       normally reverts are recommended.
> > > 
> > > I created a bot that applies commits from master to wip stable branches
> > > and tests in CI.  It runs several times a day and identifies patches
> > > that do not cherry-pick cleanly.  Branches are here:
> > > 
> > >  https://github.com/janesma/mesa/tree/wip/17.3
> > >  https://github.com/janesma/mesa/tree/wip/18.0
> > > 
> > > I've sent a couple of mails to developers when their recent patches
> > > don't apply.  So far it handles about 85% of the commits containing
> > > stable tags without intervention.
> > > 
> > 
> > Cool! I was thinking on a similar approach here:
> > 
> > * Everytime a push happens, a job/bot scans the pushed patches, and creates a
> > pull request with the stable patches. If some of the patches that does not
> > apply, then it sends an email to the authors informing.
> 
> IMO, automating messages to developers will generate undesired noise on
> mailing lists.  We should have a real person moderate the notifications,
> until they prove to be consistently actionable.
> 

Right. Actually, I think the email should be sent first to the release manager.
Because some times fixing the conflicts when the patches does not apply is quite
trivial, and it is something the release manager can do without bothering the
authors.


> > I group all the stable patches in one PR because when a push is done,
> > I assume that all the patches belong to the same feature/bugfix, and
> > thus it makes sense to deal with them as in one PR.
> 
> PRs seem like an unnecessary complication.  My proof-of-concept script
> simply applies all commits with stable tags to an arbitrary wip branch,
> based on the stable branch policies.
> 
> CI triggers from the wip branch as with any developer CI branch.
> 
> > * There's a bot that is listening for the PR. Everytime a new PR
> > arrives, it starts the proper testing. If test is successful, it
> > automatically merges the PR; otherwise it just sends an email
> > informing the failure. An important point here is that if a PR is
> > under testing, then the bot waits until the test finishes and the PR
> > under testing is either merged or rejected. If it is merged, the bot
> > rebases the new PR and starts the test. This way, we guarantee the
> > test is done with a version that won't change after while the test is
> > happening. If you are more interested, I was thinking on using Marge
> > bot for this.
> 
> Fewer/smaller dependencies is better.  What does gitlab + marge buy us
> over a single script?
> 

As I said, this is something I was thinking on implementing here locally; and as
I am using gitlab that's why I thought it around gitlab.

> To be clear, my script is gross at the moment.  I just hacked to get
> something that would match the stable policy, and provide immediate
> feedback when commits are pushed.  It could be cleaned up and shared if
> anyone wants it.
> 
> > 	J.A.
> > 
> 
>