<div dir="ltr"><div>I'd like gitlab macros :rb: and :ab: that put the tags into the comment. </div><div> </div><div>Marek </div></div> <div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Oct 12, 2021 at 5:01 PM Jason Ekstrand <<a href="mailto:jason@jlekstrand.net">jason@jlekstrand.net</a>> wrote: </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Tue, Oct 12, 2021 at 3:56 PM apinheiro <<a href="mailto:apinheiro@igalia.com" target="_blank">apinheiro@igalia.com</a>> wrote: > > > On 12/10/21 13:55, Alyssa Rosenzweig wrote: > > I would love to see this be the process across Mesa. We already don't > rewrite commit messages for freedreno and i915g, and I only have to do > the rebase (busy-)work for my projects in other areas of the tree. > > Likewise for Panfrost. At least, I don't do the rewriting. Some Panfrost > devs do, which I'm fine with. But it's not a requirement to merging. > > The arguments about "who can help support this years from now?" are moot > at our scale... the team is small enough that the name on the reviewer > is likely the code owner / maintainer, and patches regularly go in > unreviewed for lack of review bandwidth. > > There is another reason to the Rb tag, that is to measure the quantity > of patch review people do. > > This was well summarized some years ago by Matt Turner, as it was > minimized (even suggested to be removed) on a different thread: > > <a href="https://lists.freedesktop.org/archives/mesa-dev/2019-January/213586.html" rel="noreferrer" target="_blank">https://lists.freedesktop.org/archives/mesa-dev/2019-January/213586.html</a> > > I was part of the Intel team when people started doing this r-b > counting. I believe that it was being done due to Intel management's > failure to understand who was doing the work on the team and credit > them appropriately, and also to encourage those doing less to step up. > > > That's basically the same problem with trying to measure and compare developers just by commit count. In theory commit count is a bad measure for that. In practice it is used somehow. > > Unfortunately, the problem with Intel management wasn't a lack of > available information, and I didn't see publishing the counts change > reviews either. > > 💯 > > Upstream should do what's best for upstream, not for Intel's "unique" > management. > > > Not sure how from Emma explaining how Rb tags were used by Intel management it came the conclusion that it were used in that way only by Intel management. Spoiler: it is not. > > Replying both, that's is one of the reasons I pointed original Matt Turner email. He never mentioned explicitly Intel management, neither pointed this as an accurate measure of the use. Quoting: > > "The number of R-b tags is not a 100% accurate picture of the > situation, but it gives at least a good overview of who is doing the > tedious work of patch review. " > > In any case, just to be clear here: Im not saying that the Rb tags main use is this one. Just saying that is one of their uses, and the value for such use can be debatable, but it is not zero. <snark>Negative numbers aren't zero!</snark> --Jason </blockquote></div>