Hey Bastien,
On 2026-05-13 03:44, Bastien Guerry wrote:
> I recommend not mixing subject labels.
I’m fine sticking to one label in the subject! My concerns are more
about the automatic mechanism for recognizing patches.
> I see these scenarios:
>
> 1. Someone reports a bug for which they do not have a patch
> 2. Someone shares a request for which they don't have a patch
> 3. Someone shares a patch to fix/solve an existing bug/request.
> 4. Someone shares a patch *directly*
>
> The question is: what to do in the last scenario?
>
> All direct patches are already implicitly fixing a bug or addressing
> a request: explicitly adding e.g. a "BUG" label somewhere in the
> subject seems to help maintainers to understand what the patch is
> about,
> --8<--
>> In the case of a bug + fix I could just split off the patch as a
>> response, but for an RFC + patch I can’t see a way to suppress the
>> machinery.
>
> PS: I'm not sure I see the difference between bug + fix and RFC +
> patch.
I’m thinking of some other scenarios where there’s a patch, but it
isn’t intended to be applied anywhere official:
1. when you’re trying to get debugging information that isn’t
available without code changes, e.g.
Subject: Re: [BUG] something bad
I can’t reproduce or tell what’s happening there. Could you try
again with the attached patch and copy the message?
[-- Attachment … ]
2. you want feedback on a request and provide a rough patch (e.g.,
it’s inefficient, not formatted, no NEWS entry) that people can
test, e.g.
Subject: [FR] new stuff
I have a cool idea. […] Check out a rough implementation in the
attached patch.
[-- Attachment … ]
I guess you could consider #2 as a preliminary or ‘v0’ of a patch, but
IMO it would be useful to have some way to tell BARK that these
patches aren’t serious enough. In the second case you could also make
request the primary type so that voting works, e.g.
Subject: [FR] new stuff
[…]
Patch: draft
[-- Attachment … ]
> but now the report contains two things to discuss: a bug (is
> it confirmed? etc.) and its fix. "Canceled" becomes ambiguous: is
> it about the bug or the fix?
Yes I agree there’s ambiguity in general with multiple types. Maybe
the automatic bug + patch mechanism could have an exception for the
opening message, i.e. this produces a bug, and a patch linked to it:
Subject: [BUG] something bad
I found a bug and fixed it with the attached patch.
[-- Attachment … ]
> So I suggest this: either send a patch directly (and the discussion
> about the patch include the discussion about the underlying issue)
> or send two emails, one with the bug/request and one with the patch.
>
> Does this sound reasonable to you?
I’m okay doing that. Though, for patches in other contexts like
debugging and requests, I don’t think I have a choice except to leave
them out?
Thanks,
--
Jacob S. Gordon
[email protected]
Please don’t send me HTML emails or MS Office/Apple iWork documents.
https://useplaintext.email/#etiquette
https://www.fsf.org/campaigns/opendocument
