[Mesa-dev] Workflow Proposal

Jordan Justen jordan.l.justen at intel.com
Mon Oct 18 09:46:22 UTC 2021

Daniel Stone <daniel at fooishbar.org> writes:

> On Wed, 13 Oct 2021 at 20:13, Jordan Justen <jordan.l.justen at intel.com> wrote:
>> Alyssa Rosenzweig <alyssa at collabora.com> writes:
>> >
>> > Sorry, I'll make that point more emphatic.
>> >
>> > Upstream must do what's best for upstream without zero regard for the
>> > whims of management. Doubly so for bad management.
>> If the r-b process ever had any notice from any company's management, I
>> haven't seen it. (Actually, I think most management would rather have
>> the short sighted view of skipping code review to more quickly merge
>> patches.) In terms of who to "track down", that is also a tenuous
>> connection.
> All of the above is true but also totally irrelevant to the actual discussion.
> When R-b as a metric came up at the time of the first switch, I wrote
> a really trivial Python script which used the GitLab API to scrape MR
> discussions and pull 'Reviewed-by: ...' comments out and print a
> leaderboard for number of reviewed MRs over the past calendar month.
> Adapting that to look at approvals rather than comments would cut it
> down to about 10 LoC.
> Whether it's Reviewed-by in the trailer or an approval, both are
> explicitly designed to be machine readable, which means it's trivial
> to turn it into a metric if you want to. Whether or not that's a good
> idea is the problem of whoever wields it.

Correct. So let's not try to play whac-a-mole/manager/evil-genius. :)

I think several people have already said that it's good to take the time
to recognize the often overlooked and thankless job of reviewing.
Potentially stripping Reviewed-by tags seems counter to that.

Adding Approved-by from the web page could be helpful to simplify
reviews for many merge-requests. But, retaining per-patch Reviewed-by is
helpful in other cases.

So hopefully we can add Approved-by *without* destroying Reviewed-by
tags in the process. I would like to be able to use either in the cases
where they make sense.


More information about the mesa-dev mailing list