public inbox for gdb@sourceware.org
 help / color / mirror / Atom feed
From: Thiago Jung Bauermann <thiago.bauermann@linaro.org>
To: Lancelot SIX <lsix@lancelotsix.com>
Cc: Luis Machado <luis.machado@arm.com>,
	Joel Brobecker <brobecker@adacore.com>,
	gdb@sourceware.org
Subject: Re: Proposal: Add review tags to patch review workflow.
Date: Tue, 27 Sep 2022 21:07:06 +0000	[thread overview]
Message-ID: <87leq4edc5.fsf@linaro.org> (raw)
In-Reply-To: <20220927093803.7pkbrmim2o76szem@ubuntu.lan>


Hello,

Lancelot SIX via Gdb <gdb@sourceware.org> writes:

> On Tue, Sep 27, 2022 at 09:39:02AM +0100, Luis Machado via Gdb wrote:
>> So, in summary, I see the proposal to add tags as a way to improve a patch reviewing
>> system that
>> is not being capable of keeping up with demand. I doubt we would need such tagging if we
>> had a
>> proper reviewing system in place (be it gerrit, patchworks or any other).
>> 
>
> Hi,
>
> As far as I understand, patchwork can see the R-b and T-b tags and
> update patches metadata based on that.  An up-to-date patchwork instance
> is available for GDB
> (https://patchwork.sourceware.org/project/gdb/list/) and old patches
> have been archived.  It is in a clean state if we want to try using it
> (or re-try, I believe this have been tried in the past but there were
> too much limitations at the time).
>
> If R-b and T-b tags are being adopted, patchwork sounds like a good
> candidate tool to help to monitor the patches pending review/approval.
>
> What is still unknown to me at the moment is how much effort does it
> take to keep patchwork up-to-date with events it fails to detect (like
> patches merged with minor changes).  I am currently experimenting
> tracking patches with it (I think Simon is too).  Nothing compulsory to
> anyone of course.  The tool is there for those who want. The pure ML
> based workflow will not be impacted with this.   Having Bruno's proposal
> in would certainly help.

FWIW I like Bruno's proposal, it would bring clarity to the patch review
and approval process. And as Lancelot mentioned, it also helps people
using patchwork.

Carlos O'Donell mentioned at GNU Tools Cauldron that patchwork has been
very helpful for him with managing glibc patches, and that he would
still use it even if no one else in that community did since it helps
him keep track of the review state of the patches.

-- 
Thiago

  reply	other threads:[~2022-09-27 21:07 UTC|newest]

Thread overview: 35+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-09-21 11:04 Bruno Larsen
2022-09-25 22:38 ` Lancelot SIX
2022-09-26 13:55 ` Simon Marchi
2022-09-26 16:42   ` Joel Brobecker
2022-09-27  8:39     ` Luis Machado
2022-09-27  8:42       ` Luis Machado
2022-09-27  9:38       ` Lancelot SIX
2022-09-27 21:07         ` Thiago Jung Bauermann [this message]
2022-09-26 21:32   ` John Baldwin
2022-09-27  8:06     ` Bruno Larsen
2022-09-27 12:02       ` Simon Marchi
2022-09-27 12:03         ` Bruno Larsen
2022-09-27 17:11           ` John Baldwin
2022-09-27  7:58   ` Bruno Larsen
2022-09-27 12:03     ` Simon Marchi
2022-09-26 15:59 ` Luis Machado
2022-09-26 16:32   ` Elena Zannoni
2022-09-27  8:30     ` Bruno Larsen
2022-09-27 20:50 ` Thomas Schwinge
2022-10-07  7:49 ` Bruno Larsen
2022-10-07 20:46   ` Simon Marchi
2022-10-08  6:23     ` Eli Zaretskii
2022-10-08 11:55       ` Simon Marchi
2022-10-08 12:44         ` Eli Zaretskii
2022-10-09  0:29           ` Simon Marchi
2022-10-10  9:27           ` Bruno Larsen
2022-10-10  9:47             ` Eli Zaretskii
2022-10-10 10:11               ` Bruno Larsen
2022-10-10 11:27                 ` Eli Zaretskii
2022-10-10 12:31                   ` Bruno Larsen
2022-10-10 13:14                     ` Eli Zaretskii
2022-10-10 13:26                       ` Bruno Larsen
2022-10-10 15:25                         ` Eli Zaretskii
2022-10-10 13:34             ` Pedro Alves
2022-10-10  9:39     ` Luis Machado

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=87leq4edc5.fsf@linaro.org \
    --to=thiago.bauermann@linaro.org \
    --cc=brobecker@adacore.com \
    --cc=gdb@sourceware.org \
    --cc=lsix@lancelotsix.com \
    --cc=luis.machado@arm.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 read-only IMAP folder(s) and NNTP newsgroup(s).