[Mesa-dev] Thoughts after hitting 100 merge requests?

[Eric Anholt]

Daniel Stone <daniel at fooishbar.org> writes:

> Hi,
>
> On Tue, 15 Jan 2019 at 12:21, Rob Clark <robdclark at gmail.com> wrote:
>> On Tue, Jan 15, 2019 at 1:02 AM Tapani Pälli <tapani.palli at intel.com> wrote:
>> > On 1/14/19 2:36 PM, Daniel Stone wrote:
>> > > On Fri, 11 Jan 2019 at 17:05, Jason Ekstrand <jason at jlekstrand.net> wrote:
>> > > In other projects, we looked for ways to apply the tags and ended up
>> > > concluding that they didn't bring enough value to make it worthwhile.
>> > > I don't know if that holds for Mesa, but it would be better to start
>> > > with an actual problem statement - what value does R-b bring and how?
>> > > - then look at ways to solve that problem, rather than just very
>> > > directly finding a way to insert that literal text string into every
>> > > commit message.
>> >
>> > IMO it brings some 'shared responsibility' for correctness of the patch
>
> Oh, no doubt - we certainly haven't abandoned thorough review! So far
> we haven't seen that compromised by not having a name in the commit
> message.
>
>> > and quickly accessible information on who were looking at the change. So
>> > ideally later when filing bug against commit/series there would be more
>> > people than just the committer that should take a look at the possible
>> > regressions. At least in my experience people filing bugs tend to often
>> > also CC the reviewer.
>
> Yeah, that's really helpful. So maybe a useful flow - assuming we
> eventually switch to GitLab issues - would be the ability to associate
> an issue with a commit, which could then automatically drag in people
> who commented on the MR which landed that commit, as well as (at
> least) the reporter of the issue(s) fixed by that MR. That would need
> some kind of clever - probably at least semi-manual - filtering to
> make sure it wasn't just spamming the world, but it's at least a
> starting point.
>
>> +1 .. and also it is nice to see things like Reported-by/Reviewed-by
>> without having to go search somewhere else (ie. outside of git/tig)
>
> My question would again be what value that brings you. Do you just
> like seeing the name there, or do you go poke the people on IRC, or
> follow up via email, or ... ? Again I personally go look through the
> original review to see what came up during that first, but everyone's
> different, so I'm just trying to understand what you actually do with
> that information, so we can figure out if there's a better way to do
> things for everyone rather than just blindly imitating what came
> before.

I've participated in adding Reported-bys, but I've never seen the use.
It felt like "we could record this information, so we should!" rather
than solving a problem.

I've found little use in ccing reviewers on followups, except for
trivial stuff like compiler warnings.  I propose that the solution for
compiler warnings should be CI that prevents you from merging new
compiler warnings anyway.

Basically, I feel like the pain points in the MR process (amending and
re-pushing before clicking "merge") are pre-existing pain points in our
process, slightly amplified.

>> (ofc it would be pretty awesome incentive to switch to gitlab issues
>> if gitlab could automate adding Reported-by tags for MR's associated
>> with an issue.. but I guess checkbox to add Reviewed-by tag would
>> already make my day)
>
> I saw this the other day, which might be more incentive:
> https://csoriano.pages.gitlab.gnome.org/csoriano-blog/post/2019-01-07-issue-handling-automation/

Automatic needinfo closing?  Sign me up.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 832 bytes
Desc: not available
URL: <https://lists.freedesktop.org/archives/mesa-dev/attachments/20190115/44cc04e8/attachment.sig>