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

[Laurent Pinchart <laurent.pinchart@ideasonboard.com>]

Hi Don,

On Thu, Jul 08, 2021 at 05:04:36PM -0400, Don Zickus wrote:
> 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).

I'd put this slightly differently. E-mail doesn't bring ease of use by
itself. What I really want to keep from the e-mail workflow is the
following features.

- A single client where I can do all my review. With web-based UIs for
  forges, you have to log in every forge for every project you work on.
  That's one for github, one for gitlab, one for each self-hosted github
  or gitlab instance (fd.o has a self-hosted public gitlab instance,
  it's also common for large companies to have self-hosted private
  instances), and I'm not counting gerrit instances or other forges.
  It's painful, I want not only to get all the notifications in a single
  client (that's already possible with e-mail notifications) but handle
  review in a single client too.

- The ability to easily extend and customize my workflow. With web-based
  UIs, flexibility is very limited (there are APIs that allow developing
  applications to perform customization, but that's a heavy process).
  With e-mail clients, developers can pick their own clients and
  customize the workflow as they want.

Furthermore, I don't think structured data needs to be limited to
forges. Structured data can be transported over e-mail, or other
transport protocols, what we're missing is clients that could interpret
them correctly.

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

-- 
Regards,

Laurent Pinchart