ksummit.lists.linux.dev archive mirror
 help / color / mirror / Atom feed
From: Don Zickus <dzickus@redhat.com>
To: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Cc: ksummit@lists.linux.dev
Subject: Re: [Tech Topic] Integrating GitLab into the Red Hat kernel workflow
Date: Wed, 7 Jul 2021 18:27:28 -0400	[thread overview]
Message-ID: <20210707222728.jocrxvqogwjd5ozx@redhat.com> (raw)
In-Reply-To: <YOYf3c5UPMG4yBVP@pendragon.ideasonboard.com>

On Thu, Jul 08, 2021 at 12:42:53AM +0300, Laurent Pinchart wrote:
> Hi Don,
> 
> On Wed, Jul 07, 2021 at 05:19:51PM -0400, Don Zickus wrote:
> > Submission #89:
> > 
> > The Red Hat kernel team recently converted their RHEL workflow from
> > PatchWork to GitLab. This talk will discuss what the new workflow looks like
> > with integrated CI and reduced emails. New tooling had to be created to
> > assist the developer and reviewer. Webhooks were utilized to autoamte as
> > much of the process as possible making it easy for a maintainer to track
> > progress of each submitted change. Finally using CKI, every submitted change
> > has to pass CI checks before it can be merged.
> > 
> > We faced many challenges especially around reviewing changes. Resolving
> > those led to a reduction of email usage and an increase in cli tools. Demos
> > of those tools will be included.
> 
> If gitlab is used in this context (I'm talking about reviews here, not
> CI) as a transport mechanism for structured data handled by CLI tools,
> what would prevent us from developing similar tools on top of less
> centralized and proprietary transport mechanism ?

Nothing I think.  It is just api calls around abstract pieces of a review
process.

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.

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.

Thanks for the interest!

Cheers,
Don


  reply	other threads:[~2021-07-07 22:27 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 [this message]
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
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=20210707222728.jocrxvqogwjd5ozx@redhat.com \
    --to=dzickus@redhat.com \
    --cc=ksummit@lists.linux.dev \
    --cc=laurent.pinchart@ideasonboard.com \
    /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 NNTP newsgroup(s).