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

[Don Zickus <dzickus@redhat.com>]

On Sun, Jul 11, 2021 at 01:38:33AM +0300, Laurent Pinchart wrote:
> Hi Don,
> 
> > 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 biggest hurdle for reviews I see is un-authenticated email sent to an
autenticated forge.  Currently we have an email-bridge bot that copies
comments from a trusted mailing list to the forge but it is clear that the
comment is using the authenticated bot.

Some forges use an embedded personal token in the reply-to field to work
around this.  But it restricts collaboration in my opinion.

But I agree with your perspective.

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

Internally for reviewers, there are two popular use-cases.  The traditional
collaboration about the patches as you suggested and the
what-patches-need-my-attention.  As RHEL is more backport heavy (leaving
technical collaboration for upstream), we have focused more on the latter
use case, hence our tooling effort.

The former use-case is still a concern and various developers are working on
ideas to make it easier.  Suggestions like yours are welcomed.

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

Ok.  Let's say I have a couple of developers that can tweak gitlab emails to
try new ideas.  I assume X-labels only go so far.  What other thoughts do
you have that we might play around with?

Cheers,
Don

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