<div dir="ltr"><div class="gmail_quote"><div dir="ltr">On Tue, Jan 15, 2019 at 12:52 PM Eric Anholt <<a href="mailto:eric@anholt.net">eric@anholt.net</a>> wrote: </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Daniel Stone <<a href="mailto:daniel@fooishbar.org" target="_blank">daniel@fooishbar.org</a>> writes: > Hi, > > On Tue, 15 Jan 2019 at 12:21, Rob Clark <<a href="mailto:robdclark@gmail.com" target="_blank">robdclark@gmail.com</a>> wrote: >> On Tue, Jan 15, 2019 at 1:02 AM Tapani Pälli <<a href="mailto:tapani.palli@intel.com" target="_blank">tapani.palli@intel.com</a>> wrote: >> > On 1/14/19 2:36 PM, Daniel Stone wrote: >> > > On Fri, 11 Jan 2019 at 17:05, Jason Ekstrand <<a href="mailto:jason@jlekstrand.net" target="_blank">jason@jlekstrand.net</a>> 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. </blockquote><div> </div><div>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... </div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> 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: > <a href="https://csoriano.pages.gitlab.gnome.org/csoriano-blog/post/2019-01-07-issue-handling-automation/" rel="noreferrer" target="_blank">https://csoriano.pages.gitlab.gnome.org/csoriano-blog/post/2019-01-07-issue-handling-automation/</a> Automatic needinfo closing? Sign me up. _______________________________________________ mesa-dev mailing list <a href="mailto:mesa-dev@lists.freedesktop.org" target="_blank">mesa-dev@lists.freedesktop.org</a> <a href="https://lists.freedesktop.org/mailman/listinfo/mesa-dev" rel="noreferrer" target="_blank">https://lists.freedesktop.org/mailman/listinfo/mesa-dev</a> </blockquote></div></div>