[PATCH] RFC: CONTRIBUTING: Embrace gitlab

Daniel Stone daniel at fooishbar.org
Thu Sep 13 12:50:24 UTC 2018


Hey Ville,

On Thu, 13 Sep 2018 at 11:52, Ville Syrjälä
<ville.syrjala at linux.intel.com> wrote:
> On Thu, Sep 13, 2018 at 11:31:31AM +0100, Daniel Stone wrote:
> > On Thu, 13 Sep 2018 at 09:54, Jani Nikula <jani.nikula at intel.com> wrote:> > > If the acks and reviews aren't recorded in git log for each commit, they
> > > don't exist.
> >
> > To be fair, given that DRM is about the only subsystem doing it, does
> > recording it in a fixed format in the commit matter? ;)
>
> Answering despite the ";)" :)

It's more of an answer than it deserved! Thanks.

> Helps when answering questions like:
> - Who might be able review my stuff?

Yeah, having this easily collated is really helpful. Exposing that
better through the web interface would be nice. The issue I linked to
in the previous message would probably be a good entry point for
exploring how to better expose this through the GitLab UI and API. My
current workflow is to take the commit SHA, go to
https://gitlab.freedesktop.org/wayland/weston/commit/SHA1, then click
through the MR. Not the most optimal thing, but compared to however
long I spent trying to diagnose the bug before giving up and deciding
I needed to talk to the author, pretty much a drop in the ocean.

> - Who can I blame for a regression/bug?

All the people who didn't review it as well?

> - Who do I need to poke on irc to figure out what is going
>   on when the patch/commit msg are a mess?

This is _definitely_ an earlier failure.

> - How well was this thing actually reviewed? Often somewhat
>   decently approximated by just "who done it?"

I gave up at the point where I realised R-b and A-b threw away tons of
information. A lot of commit messages carry those tags from me, with
all the communication around it skipped. Stuff like 'this seems
correct to me and builds but I don't understand FreeRDP at all', or
'this improves things but doesn't fix the root problem for which a lot
more work is needed, but we'll take this minimal fix before the
release', or whatever. I found that I was spending half my time
digging through mail archives anyway to find out what the person
actually said, and what their reservations (if any) were. Quite a few
times I found comments to the effect of 'this is fine, but the obvious
follow-on work to fix the underlying issue is a/b/c/d', which would be
the real answer to my question. And despite however many years of
mutt, I still find it way quicker to click through the full review
history through the web MR interface than scanning through all the
mails. But again, that's me and my projects: YMMV.

> I suppose if there would a be tool to suck those out from gitlab
> when you need them given a specific commit it might work out.
> Although that doesn't sound quite as efficient as just having
> the information there in the commit msgs.

Thinking out loud, I wonder if the `glim` tool couldn't take all the
MR review notes with a certain string in them (or just all the
top-level notes) and attach them with git notes?

Cheers,
Daniel


More information about the dim-tools mailing list