On 15/1/19 7:01, Tapani Pälli wrote: > > > On 1/14/19 2:36 PM, Daniel Stone wrote: >> Hi, >> >> On Fri, 11 Jan 2019 at 17:05, Jason Ekstrand <ja...@jlekstrand.net> >> wrote: >>> 5. There's no way with gitlab for Reviewed-by tags to get >>> automatically applied as part of the merging process. This makes >>> merging a bit more manual than it needs to be but is really no worse >>> than it was before. >> >> I'm still on the side of not seeing the value in them. Most of the >> time when I go to pursue someone who reviewed a commit, I'll go to see >> what came up in review anyway. Maybe someone had the same comment >> which was found to be not applicable or otherwise explained away. >> Reviewed-by and Acked-by are also pretty lossy anyway, and freeform >> text descriptors in a comment can much better capture the intent (e.g. >> 'I'm strongly OK with the driver changes and weakly OK with the core >> changes as it's not really my area of expertise'). >> >> 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 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.
In addition to that, it is also useful for big series that are updated several times, as is a way to know which patches were already reviewed and which not, so reviewer can focus on the latter. > >> FWIW, if you go to >> https://gitlab.freedesktop.org/mesa/mesa/commit/SHA1 then you get a >> hyperlink from the web UI which points you to the MR. The API to do >> this is pretty straightforward and amenable to piping through jq: >> https://docs.gitlab.com/ce/api/commits.html#list-merge-requests-associated-with-a-commit >> > > I guess if we would move issue tracking to gitlab then we could > possibly automate the CC list generation based on commit? > > // Tapani > _______________________________________________ > mesa-dev mailing list > mesa-dev@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/mesa-dev
pEpkey.asc
Description: application/pgp-keys
_______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev