[Mesa-dev] [ANNOUNCE] mesa 21.3.0-rc1
Hello everyone! Once again, a new release cycle has started. Please test this first release candidate, and report any issue here: https://gitlab.freedesktop.org/mesa/mesa/-/issues/new Issues that should block the release of 21.3.0 should be added to the corresponding milestone: https://gitlab.freedesktop.org/mesa/mesa/-/milestones/27 Cheers, Eric --- git tag: mesa-21.3.0-rc1 https://mesa.freedesktop.org/archive/mesa-21.3.0-rc1.tar.xz SHA256: f1ec269b7db6568347e554fdbe42e09e1632ac5f6a48913e0fb3def654749d95 mesa-21.3.0-rc1.tar.xz SHA512: 346e120e5ac00fbb8ed507765d84d2c54b739595dde24a8c1a9cd19b705ea3e9c3171fbd457e4ace3089eebcf7d293f845568f7b52228ef958e9ef959013 mesa-21.3.0-rc1.tar.xz PGP: https://mesa.freedesktop.org/archive/mesa-21.3.0-rc1.tar.xz.sig signature.asc Description: PGP signature
Re: [Mesa-dev] Workflow Proposal
Alyssa Rosenzweig writes: >> 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. > > Sorry, I'll make that point more emphatic. > > Upstream must do what's best for upstream without zero regard for the > whims of management. Doubly so for bad management. If the r-b process ever had any notice from any company's management, I haven't seen it. (Actually, I think most management would rather have the short sighted view of skipping code review to more quickly merge patches.) In terms of who to "track down", that is also a tenuous connection. The value of r-b is to give reviewers credit for the hard work that they do. (Which, I believe is what Matt and apinheiro are also saying.) Personally I try to make a rework log on patch commit messages to give reviewers more explicit credit for changes that are made based on their code review. I hope Marge Bot doesn't start stripping the r-b tags. But, if Marge can add Approved-by which allows the review process to flow more quickly for some types of merge-requests, then I think that's a good thing. I wouldn't be surprised if this became the most commonly used review process in Mesa. -Jordan
Re: [Mesa-dev] Workflow Proposal
> > >> 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.
Re: [Mesa-dev] Workflow Proposal
> 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. Sorry, I'll make that point more emphatic. Upstream must do what's best for upstream without zero regard for the whims of management. Doubly so for bad management.
