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

[Dylan Baker]

Quoting Jason Ekstrand (2019-01-15 11:57:01)
> On Tue, Jan 15, 2019 at 12:52 PM Eric Anholt <eric at anholt.net> wrote:
> 
>     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.
> 
> 
> To me, the Reported-by tag is more for giving credit than anything else.  Maybe
> it doesn't matter but some people appreciate it when their contributions, even
> if it's just a good bug report, are recorded in the project's permanent
> record.  It's also a good way to make sure the reporter gets CCd on the patch
> so they can verify it fixes the bug for them.  That said, bugzilla is a
> permanent record and the information would be even more accessible if we just
> used GitLab MRs...

If we used gitlab issues with a Fixes #123 tag the reporter and all subscribers
would be notified and there would still be a permanent record.

Dylan

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

Yes please!
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: signature
URL: <https://lists.freedesktop.org/archives/mesa-dev/attachments/20190115/039a3f29/attachment.sig>