On Tue, Jan 15, 2019 at 12:52 PM Eric Anholt <e...@anholt.net> wrote:
> 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. > 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... > 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. > _______________________________________________ > mesa-dev mailing list > mesa-dev@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/mesa-dev >
_______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
