Creating a tag to track partial reviews: "Consulted:"

DJ Delorie dj@redhat.com
Thu May 8 16:39:02 GMT 2025


"Carlos O'Donell" <carlos@redhat.com> writes:
> There is a *secondary* goal here, as Consulted: allows the Monday Morning
> Patch Queue review to *easily find* potential reviewers for new versions
> of the patch based on old reviewers rather than tracking the mailing list
> data.

Patchwork records all the replies to any patch; it will have that list
for you.  Unless we propose to add more magic flags to what patchwork
looks for, I don't see a new tag - which you'd have to scan the emails
for anyway - to be of particular benefit here.

> DJ's earlier comments:
>
> (1) Is it superfluous?
>
> - No. You have to opt-in with a tag rather than just assume an email does that.

I mean, a reply might say "I don't think this is a good idea.  Also,
Consulted-by: me".  The first sentence has all the info, and a
"Consulted-by:" *without* the extra text is meaningless.  Since you have
to have the extra text anyway...

And every Consulted-by either eventually gets ignored, or replaced by a
Reviewed-by.  There's no way to retract a Consulted-by, but in plain
text you can explain that you've changed your mind.

Compared to reviewed-by where the tag itself has real value, even
without other text to explain it.

So: a consulted-by always needs "helper text" to explain it, and "helper
text" to resolve it.  I.e. it's superfluous.

> (2) It adds extra work for patch authors?
>
> - Yes it does, and this part makes it annoying, but with tooling like b4 we should

We don't use b4, do we?

> (3) What about opposition to consensus tag?
>
> - This is a distinct topic. A tag for "hard no" would indeed be useful, since we
>    identify that in our process e.g. Rejected-by: would require two things:
>    (a) validity of the rejection (concerned interest or not) and (b) subsequently
>    resolving it (you can resolve it even if (a) is not from a concerned interest).

Consulted-by is already a "soft no".  So we have a hard yes and a soft
no... but no soft yes or hard no.  I don't like this kind of
inconsistency because it requires more documentation.

Reviewed-by:
I-didn't-see-anything-wrong-with-it-by:
Consulted-by:
Rejected-by:

Maybe "reviewed-by" is the problem case?  Should it have been
"Approved-by" instead?  If one reviews a patch and finds problems,
they've still reviewed it.



More information about the Libc-alpha mailing list