Daniel Stone <dan...@fooishbar.org> writes: > Hi, > > On Tue, 15 Jan 2019 at 12:21, Rob Clark <robdcl...@gmail.com> wrote: >> On Tue, Jan 15, 2019 at 1:02 AM Tapani Pälli <tapani.pa...@intel.com> wrote: >> > On 1/14/19 2:36 PM, Daniel Stone wrote: >> > > On Fri, 11 Jan 2019 at 17:05, Jason Ekstrand <ja...@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.
signature.asc
Description: PGP signature
_______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
