Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Eli Zaretskii via Gdb-patches <gdb-patches@sourceware.org>
To: Kevin Buettner <kevinb@redhat.com>
Cc: blarsen@redhat.com, gdb-patches@sourceware.org, pedro@palves.net,
	aburgess@redhat.com, brobecker@adacore.com,
	simon.marchi@polymtl.ca, tom@tromey.com, tdevries@suse.de,
	ulrich.weigand@de.ibm.com
Subject: Re: [PATCH v3 0/1] update MAINTAINERS file with git trailers
Date: Fri, 14 Jul 2023 08:50:28 +0300	[thread overview]
Message-ID: <83h6q73uu3.fsf@gnu.org> (raw)
In-Reply-To: <20230713145047.358e2c4a@f37-zws-nv> (message from Kevin Buettner on Thu, 13 Jul 2023 14:50:47 -0700)

> Date: Thu, 13 Jul 2023 14:50:47 -0700
> From: Kevin Buettner <kevinb@redhat.com>
> Cc: gdb-patches@sourceware.org, pedro@palves.net, aburgess@redhat.com,
>  brobecker@adacore.com, simon.marchi@polymtl.ca, tom@tromey.com,
>  tdevries@suse.de, ulrich.weigand@de.ibm.com, eliz@gnu.org
> 
> On Thu, 13 Jul 2023 12:56:51 +0200
> Bruno Larsen <blarsen@redhat.com> wrote:
> 
> > Right now there is one big unanswered question: Should we have a
> > specific tag to explicitly signal when a patch has been partially
> > approved? Eli asked for it to avoid people mechanically reading tags
> > from thinking that a patch has been fully approved when it was only
> > partial.
> 
> I don't think we need a tag for this.  Since we review and/or approve
> patches via email, I think some additional text stating which portions
> were reviewed or approved is sufficient.
> 
> Suppose I'm an area maintainer or a global maintainer who has confident
> knowledge of a particular area.  I might then do something like this:
> 
>     For the mn10300 architecture portions:
>     Approved-by: Kevin Buettner <kevinb@redhat.com>
> 
> Only the Approved-by tag would be added to the git trailer, but it's
> clear to anyone involved in the approval process that I haven't
> approved the patch in its entirety, only certain parts.  If I were to
> review the rest of the patch, but not approve it, I see nothing wrong
> with also saying:
> 
>     For everything else:
>     Reviewed-by: Kevin Buettner <kevinb@redhat.com>
> 
> I also see nothing wrong with qualifying the 'Reviewed-by' or
> 'Acked-by' tags.  Yes, we might end up with a patchwork of reviews,
> but we might also get more people involved with the review process,
> which I think would be a good thing.
> 
> If we really want to include the portions reviewed in the trailer, then
> I suggest extending the format of the trailer, perhaps like this:
> 
>     Approved-by: Kevin Buettner <kevinb@redhat.com> (mn10300 only)

The above will only work if everyone pays attention to those
qualifications.  Moreover, in Real Life, the response doesn't include
just two such lines, it in many cases includes more text, and those
qualifications can easily "drown" in that.

Also, we used to have a way of saying "Approved, if those few nits are
fixed", and the above either removes that possibility entirely, or
will make it harder to determine whether and which parts were
approved, and on what conditions.

I still don't understand why we need the "partial-approved" facility
that uses Approved-by.  How is it different from Reviewed-by? the
submitter still needs to figure out whether all the parts were okayed
or not, so the only aspect this changes is making it more complicated
for area maintainers to write these tags, because instead of just a
single Reviewed-by they need to choose among two tags.

So my vote is for reserving Approved-by only to the cases where the
entire patch is approved.  Alternatively, we could introduce an
additional tag, like Partially-approved-by or something.

I guess my point is that this should be simple and ideally include
only fixed text, not some free-form text that could lead to
misunderstandings and misinterpretations.

  reply	other threads:[~2023-07-14  5:50 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-07-13 10:56 Bruno Larsen via Gdb-patches
2023-07-13 10:56 ` [PATCH v4 1/1] [gdb]: add git trailer information on gdb/MAINTAINERS Bruno Larsen via Gdb-patches
2023-07-13 21:24   ` Kevin Buettner via Gdb-patches
2023-07-13 21:50 ` [PATCH v3 0/1] update MAINTAINERS file with git trailers Kevin Buettner via Gdb-patches
2023-07-14  5:50   ` Eli Zaretskii via Gdb-patches [this message]
2023-07-14 10:11     ` Bruno Larsen via Gdb-patches
  -- strict thread matches above, loose matches on Subject: below --
2023-06-28 12:42 Bruno Larsen via Gdb-patches

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=83h6q73uu3.fsf@gnu.org \
    --to=gdb-patches@sourceware.org \
    --cc=aburgess@redhat.com \
    --cc=blarsen@redhat.com \
    --cc=brobecker@adacore.com \
    --cc=eliz@gnu.org \
    --cc=kevinb@redhat.com \
    --cc=pedro@palves.net \
    --cc=simon.marchi@polymtl.ca \
    --cc=tdevries@suse.de \
    --cc=tom@tromey.com \
    --cc=ulrich.weigand@de.ibm.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