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

[Mark Janes]

"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.

> 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?

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.
>