> > >> 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: > > > > https://lists.freedesktop.org/archives/mesa-dev/2019-January/213586.html > > 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. > 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.
