[Mesa-dev] [PATCH v2] docs: Document GitLab merge request process (email alternative)

Dylan Baker dylan at pnwbakers.com
Thu Dec 13 17:58:23 UTC 2018


Quoting Alex Deucher (2018-12-13 07:52:04)
> On Wed, Dec 12, 2018 at 3:42 AM Samuel Pitoiset
> <samuel.pitoiset at 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: signature
URL: <https://lists.freedesktop.org/archives/mesa-dev/attachments/20181213/029f5181/attachment.sig>


More information about the mesa-dev mailing list