On Tue, Jan 15, 2019 at 7:40 AM Daniel Stone <dan...@fooishbar.org> wrote: > > 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.
If I am curious or have some questions about why some code is the way it is I frequently use tig-blame, which makes it easy to step into the commit that made the change and see the commit msg and r-b tags.. I guess the most important part if I need to ping someone on IRC w/ questions is the author, but it seems like having the other tags handy without context-switching to browser/gitlab is useful. I guess I don't as frequently dig into the history of the original patchset and it's review comments.. mostly because that isn't as easy with the email based review process. Making this easier would defn be a win. But in cases where I don't have to leave the comfort of tig, it would be nice not to have to start doing so.. This is not an argument for sticking to email based process, just defence of what I think would be a useful feature for gitlab to gain ;-) (Also, I suppose preserving those artifacts of "the old process" is probably useful for folks who run git statistics, although personally that does not effect me.) BR, -R > > (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/ > > Cheers, > Daniel _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
