I noticed that gitlab breaks formatting of <[email protected]>. It removes < and >, and converts the address to a hyperlink. I can preserve the formatting by enclosing the comment in ` ... `.
Marek On Tue, Jan 15, 2019 at 1:52 PM Eric Anholt <[email protected]> wrote: > Daniel Stone <[email protected]> writes: > > > Hi, > > > > On Tue, 15 Jan 2019 at 12:21, Rob Clark <[email protected]> wrote: > >> On Tue, Jan 15, 2019 at 1:02 AM Tapani Pälli <[email protected]> > wrote: > >> > On 1/14/19 2:36 PM, Daniel Stone wrote: > >> > > On Fri, 11 Jan 2019 at 17:05, Jason Ekstrand <[email protected]> > 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. > _______________________________________________ > mesa-dev mailing list > [email protected] > https://lists.freedesktop.org/mailman/listinfo/mesa-dev >
_______________________________________________ mesa-dev mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/mesa-dev
