Quoting Alex Deucher (2018-12-13 07:52:04) > On Wed, Dec 12, 2018 at 3:42 AM Samuel Pitoiset > <samuel.pitoi...@gmail.com> wrote: > > > > Personally, I will continue to use the list, at least for a simplicity > > point of view. I'm not sure if using a new tool will improve quality and > > code review process. > > > > Though, if the majority reports that is really nice to use, I will > > probably change my mind. Not a strong reject. > > I agree. We've been using the MR interface for xf86-video-amdgpu and > I find it awkward compared to the mailing list. Maybe it just takes > getting used to. I also feel less inclined to do drive by patch > review if I have to explicitly delve into the browser to look at the > outstanding MRs. Over email, sometimes I see a patch set in my in box > that piques my interest and I find some time to review it when I might > not have otherwise if the bar were higher. > > Out of curiosity what do others like about the MR interface? How are > you using it? What advantages does it give you over the mailing list? > I feel like maybe I'm not using it right or missing features that > make it more useful and less awkward. I feel like the interface makes > it harder than it needs to be to see the actual changes in MR to be > reviewed. All of the links click through to the source view rather > than the patch view. > > Alex
My perspective is based on the two other projects I work on, meson and alot (which, incidentally, I started working on alot because doing patch review on mailing lists is such a pain) - Using MRs drives a *lot* of drive by, one time, contributors. They run into some bug, write a patch, send an MR, and it's that easy. - It's easy to see all of the issues I've opened, and MRs I've opened (and the closed vs still open ones) quickly and easily. This makes tracking my outstanding work much easier (and is something I struggle with greatly) - All review happens in the same view. As I read the code I immediately see what other reviewers have said, which saves getting the same review comment multiple times and prevents conflicting review - by tagging issues (ala, Fixes #1234) in the commit message then pushing the commit the issue is automatically closed. This is super nice both to keep the bug tracker tidy and to figure out why an issue was closed. - not dealing with git am - V2s are automatically updated, and you can see the changes easily between various versions, as well as when each version was sent - Doesn't require huge setup to become efficient. I have now set up a pretty complicated email setup with notmuch+alot+afew to get tagging, open things in vim, added countless macros to vim, and sunk countless hours into alot to be able to do patch review efficiently. With github and gitlab, I open firefox, log in, and start doing work. - tags make it easy to see that something does or doesn't affect an area of the mesa that I know/care about My perspective coming into mesa was the doing mailing list review was very daunting and scary. There are a lot of rules that are expected that common clients (gmail) don't respect (don't send HTML mail), use inline comments, snip long quotes when they're not relevant. MRs take a lot of that away. We don't have to train people to use git-send-email *and* help them get it all set up. Hopefully that helps, Dylan
signature.asc
Description: signature
_______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
