[PATCH] RFC: CONTRIBUTING: Embrace gitlab

[Jani Nikula]

On Thu, 13 Sep 2018, Daniel Stone <daniel at fooishbar.org> wrote:
> 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?

The primary question is how valuable we think the metadata is. That
defines where it should be stored. 

For example, I think the Reviewed-by/Acked-by tags are important enough
to warrant storing them in the commit message, which is the primary
place for commit metadata.

The trouble with storing metadata in a gitlab instance is that it's
centralized as opposed to the decentralized nature of git
itself. Perhaps there are ways to extract the data using their APIs, but
I presume you can't just git clone the data. Running your own gitlab
instance is of course better in this regard than having all the eggs in
one giant shared basket run by a corporation, but it's still
centralized.

Arguably reviews on mailing lists are also decentralized metadata, but
it's difficult to argue that would be convenient, at least not if you
don't have the messages you want in your local mail store. But you you
can still find the review threads eons later using our message-id based
Link: URLs even after the patchwork server is long gone.

Contrast this with our Bugzilla: links which are only useful as long as
the fdo bugzilla is up and running. The day the plug is pulled on it,
all that metadata is rendered useless. Relying on gitlab for metadata
storage is a similar thing.

As to git notes, I don't have experience with sharing them on a larger
scale myself, but I've been told they are not as convenient to
distribute as the repository itself.


BR,
Jani.


-- 
Jani Nikula, Intel Open Source Graphics Center