Re: [Tech Topic] Integrating GitLab into the Red Hat kernel workflow

[Don Zickus <dzickus@redhat.com>]

On Thu, Jul 08, 2021 at 01:40:17AM +0300, Laurent Pinchart wrote:
> > If as a reviewer you want to see:
> > * all patches that touch files/directories X, Y, Z
> > * all discussions around those patches
> > * who has approved the patch
> > * who is blocking the patch
> > * has it passed CI
> > * other details
> > 
> > then the tool just calls whatever api to whatever tool to put all that
> > together and present it to you.  GitLab structured data in a way to allow us
> > to rethink things and we built a tool around this new approach.  I am sure
> > it can't be that hard to abstract further and extend it to other tools if
> > that is interesting.
> 
> In that workflow, how does a reviewer enter review data ? Does it have
> to go through the gitlab web UI, or do you have alternate means through
> CLI tools and/or e-mail bridges ?

Currently we are using an email bridge as the tool stabilizes and GitLab
resolves some of the quirks we have identified.  But our email bridge stats
show very few developers are using email as most have migrated to the cli
tools.

> 
> One particular shortcoming of gitlab that I've noticed is that it
> doesn't seem to be possible to comment inline on a commit message. I
> don't know if it's a limitation of the UI only, or if the protocol and
> data formats also don't support that. Good commit messages are very
> important, and I believe a tool that doesn't let me comment on how to
> improve a commit message could cause the overall quality of the
> development to decrease over time. Have you noticed the same
> shortcoming, and if so, have you found ways to address it ?

Yes and we raised it with GitLab.  We will work with them to see if it is
possible to fix this year.

> 
> > Email workflow works great.  But as PatchWork showed us, there are some
> > extra details or tracking that is interesting to some folks.  With GitLab we
> > extend this a little further.
> > 
> > It really depends on what you want to see when you review a patch.
> 
> E-mail is very limited by itself when it comes to tracking information.
> Services like patchwork help there, but they're limited by the fact that
> data isn't structured. Services such as git..b have an advantage in that
> front. When it comes to doing the actual review, however, I believe the
> situation is the opposite. I'm dreaming of a way to move our e-mail
> workflow from unstructured to structured data in order to get the best
> of both worlds, with services that can then subscribe to the mailing
> lists (which are really transport mechanisms) to gather data and expose
> it in useful ways. I have high hopes that the work done by Konstantin
> and others will bring us in that direction.

Yes, we are still tweaking our workflow too, to find that balance for
collaboration between ease-of-use (email) and structured data (gitlab).

We even have a public-inbox prototype that connects with the GitLab API and
allows you to reply with some mutt hacking.  Not sure if that is a useful
direction for you.

But yes, internally, patch review has been our most discussed topic.

Cheers,
Don