[PATCH] RFC: CONTRIBUTING: Embrace gitlab

[Daniel Vetter]

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.

Yeah I think these tags should be kept for sure. Ideally also anything
important captured in the commit message. But practice says that one's
already wishful thinking too often - or just way too hard to tell which
seeminigly irrelevant bits of information will be needed in the future.

> 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.

Yup, that's at least for me a huge reason to not entertain github.com at
all. If the Sun sets on that one and it becomes an Oracle, there's no way
out. Kernel already had that experience in some fasion with bitkeeper.

> 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.

Ime the final rounds of a tricky patch series only contain the bikesheds,
all the design decisions happened in the earlier rounds. Which only google
will find (if you're lucky). Merge requests could store all these behind
just one Link:

> 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.

>From my pov, gitlab, bugzilla and mailing list archives all have the same
problem that if the server goes down, it's next to useless. We're slightly
better after gmane went down, but personally I don't store an archive
either. And I think most people are in the same boat. So if fd.o mail
archives and patchwork go poof, it's as lost as when bugzilla or gitlab
goes poof. A good sized disaster either way :-/

Daniels also said that you can tarball everything if you feel like
sufficiently paranoid, and confident enough that you keep the data around
better than fd.o admins. There's still the problem that all the links are
effectively dead (even if you can easily find the right pulls again with
your local dump).

Anyway, I think if fd.o goes down/gets taken over by Oracle, then we're
screwed no matter which tooling we're using.

> 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.

Yeah iirc git notes have special branches and merging them is a pain. So
technically they work as well as git push/pull, practically, not so much.
Especially once the behind-the-scenes magic starts breaking down, and you
need to resolve conflicts and stuff.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch