[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