[PATCH] RFC: CONTRIBUTING: Embrace gitlab

[Ville Syrjälä]

On Thu, Sep 13, 2018 at 04:42:02PM +0300, Jani Nikula wrote:
> 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.

Wild idea: Feed the mailing lists into a public git repo? Not sure how
crazy that would be.

-- 
Ville Syrjälä
Intel