[PATCH] RFC: CONTRIBUTING: Embrace gitlab

[Ville Syrjälä]

On Thu, Sep 13, 2018 at 11:31:31AM +0100, Daniel Stone wrote:
> Hi,
> 
> On Thu, 13 Sep 2018 at 09:54, Jani Nikula <jani.nikula at intel.com> wrote:
> > On Wed, 12 Sep 2018, Daniel Vetter <daniel.vetter at ffwll.ch> wrote:
> > > On Wed, Sep 12, 2018 at 7:50 PM, Sean Paul <sean at poorly.run> wrote:
> > >> Given the size of this repo and the number of contributors, I'm not
> > >> convinced either of these should be blockers. We should avoid merge
> > >> commits since the volume is low enough that having to rebase should
> > >> be quite rare. Reviews and acks will be recorded in the merge request,
> > >> which is easily accessed from the UI.
> > >
> > > Not sure recording review&acks on the merge request is going to fly
> > > for kernel. And that's kinda what I want to test-drive here, in 1st
> > > gear :-)
> >
> > 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 ";)" :)

Helps when answering questions like:
- Who might be able review my stuff?
- Who can I blame for a regression/bug?
- Who do I need to poke on irc to figure out what is going
  on when the patch/commit msg are a mess?
- How well was this thing actually reviewed? Often somewhat
  decently approximated by just "who done it?"

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.

-- 
Ville Syrjälä
Intel