Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Guinevere Larsen <guinevere@redhat.com>
To: Eli Zaretskii <eliz@gnu.org>
Cc: gdb-patches@sourceware.org
Subject: Re: [PATCH 6/6] gdb/record: Define new version of the record-save section
Date: Thu, 16 Apr 2026 11:03:16 -0300	[thread overview]
Message-ID: <a437ffd7-4326-441a-8b0c-3d53b4292f13@redhat.com> (raw)
In-Reply-To: <86bjfjkoi5.fsf@gnu.org>

On 4/16/26 10:45 AM, Eli Zaretskii wrote:
>> Date: Thu, 16 Apr 2026 09:41:56 -0300
>> Cc: gdb-patches@sourceware.org
>> From: Guinevere Larsen <guinevere@redhat.com>
>>
>>> Reviewed-By: Eli Zaretskii <eliz@gnu.org>
>>>
>> This is confusing to me. You're supposed to add the review tag when
>> you're satisfied with the patch and approving it to go through.
> That's not my understanding, since I'm reviewing only part of the
> patch.  What I usually do is say when I'm satisfied is "this part is
> OK" or "the documentation parts are approved".

The point of the review tag is specifically to remove the ambiguity of 
needing to look for ambiguous language like "this part is ok". As the 
MAINTAINERS file explains

- Reviewed-By:

   Used when a contributor has looked at the code and agrees with
   the changes, but either doesn't have the authority or doesn't
   feel comfortable approving the patch.

If you would like further changes, you  don't agree with them just yet, 
therefore you shouldn't be using the tag. It is here to create a very 
obvious "no further discussion is required" demarcation on the list, 
which your usage does not follow

>
>> So, do you think the explanation I gave is enough, or do you want me
>> to explain it more on the news file?
> I'd prefer that you at least mention the command(s) which produce and
> read these execution records, so that people know what is affected.
Ok will do.
>
> Thanks.
>

-- 
Cheers,
Guinevere Larsen
It/she


  reply	other threads:[~2026-04-16 14:04 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-04-15 18:58 [PATCH 0/6] Refactor the internals of record-full Guinevere Larsen
2026-04-15 18:58 ` [PATCH 1/6] gdb/record: Refactor record history Guinevere Larsen
2026-04-15 18:58 ` [PATCH 2/6] gdb/record: remove record_full_insn_num Guinevere Larsen
2026-04-15 18:58 ` [PATCH 3/6] gdb/record: c++ify internal structures of record-full.c Guinevere Larsen
2026-04-15 18:58 ` [PATCH 4/6] gdb/record: make record_full_history more c++-like Guinevere Larsen
2026-04-15 18:58 ` [PATCH 5/6] gdb/record: extract the PC to record_full_instruction Guinevere Larsen
2026-04-15 18:58 ` [PATCH 6/6] gdb/record: Define new version of the record-save section Guinevere Larsen
2026-04-16  6:00   ` Eli Zaretskii
2026-04-16 12:41     ` Guinevere Larsen
2026-04-16 13:45       ` Eli Zaretskii
2026-04-16 14:03         ` Guinevere Larsen [this message]
2026-04-16 15:01           ` Eli Zaretskii

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=a437ffd7-4326-441a-8b0c-3d53b4292f13@redhat.com \
    --to=guinevere@redhat.com \
    --cc=eliz@gnu.org \
    --cc=gdb-patches@sourceware.org \
    /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