From: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
To: Don Zickus <dzickus@redhat.com>
Cc: ksummit@lists.linux.dev
Subject: Re: [Tech Topic] Integrating GitLab into the Red Hat kernel workflow
Date: Thu, 15 Jul 2021 02:47:07 +0300 [thread overview]
Message-ID: <YO93e9tTMfFwupHy@pendragon.ideasonboard.com> (raw)
In-Reply-To: <20210712135835.qgh7u5f7p2oy7cp5@redhat.com>
Hi Don,
On Mon, Jul 12, 2021 at 09:58:35AM -0400, Don Zickus wrote:
> On Sun, Jul 11, 2021 at 01:38:33AM +0300, Laurent Pinchart wrote:
> > > 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?
One idea I've been thinking about (and it's probably not a very good
one, but maybe someone can think of a way to make it better) is to
create a structured format very similar to regular e-mails. It would be
readable by humans in a normal e-mail client, and wouldn't break when
replying if enough care was taken by the responder (assuming an e-mail
client that is not inherently completely broken). Any bad reply would
break the flow, but "good" replies wouldn't. With this as a starting
point, we could start developping support in e-mail clients (I'm
selfishly thinking about mutt in particular, but I can imagine a few
other open-source clients doing the same) and text editors (for clients
that use external editors) to interpret the structured data and generate
correct replies without relying on the user doing the work themselves.
This could give us a path towards a gradual transition. Forges that
receive broken replies could possibly also implement heuristics to still
make sense of the replies (to some extent at least), possibly only in a
transitory period.
Now that I've explained my bad idea, does anyone think of a way to turn
it into a good idea ? :-)
> > > 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
next prev parent reply other threads:[~2021-07-14 23:47 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-07-07 21:19 [Tech Topic] Integrating GitLab into the Red Hat kernel workflow Don Zickus
2021-07-07 21:42 ` Laurent Pinchart
2021-07-07 22:27 ` Don Zickus
2021-07-07 22:40 ` Laurent Pinchart
2021-07-08 21:04 ` Don Zickus
2021-07-10 22:38 ` Laurent Pinchart
2021-07-12 13:58 ` Don Zickus
2021-07-12 19:07 ` Konstantin Ryabitsev
2021-07-14 16:35 ` Don Zickus
2021-07-14 23:47 ` Laurent Pinchart [this message]
2021-07-09 14:59 ` ketuzsezr
2021-07-12 13:30 ` Don Zickus
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=YO93e9tTMfFwupHy@pendragon.ideasonboard.com \
--to=laurent.pinchart@ideasonboard.com \
--cc=dzickus@redhat.com \
--cc=ksummit@lists.linux.dev \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).