Hey Bastien, Apologies for the delay and thanks for the quick response!
On 2026-05-14 06:41, Bastien wrote: > - The label in the subject ([BUG], [PATCH], [POLL], ...) now decides > a report's type, replacing the previous "patch content always > wins". > > - So a [BUG] with a .patch attachment is now a :bug, not a :patch, > but still keeps the patch metadata on the bug entity. This does the right thing in all the examples I kept. If the initial patch does end up being applied, it could just be clarified when closing the original report (or not), e.g. Subject: Re: [BUG] something bad Fixed, by the patch in the original report applied as ‘5f8fe990e’ on bugfix. On 2026-05-14 07:22, Rens Oliemans wrote: > I guess my intuition is that false negatives are worse than false > positives, but perhaps others (who frequent the tracker more than I > do) might disagree. 1+, it’s easier to identify false positives in the tracker and deal with them than to search the archives manually for false negatives. On 2026-05-14 06:41, Bastien wrote: > - What about a reply to a bug/request shipping .patch attachment or > an inline diff? It is not recognized as a standalone patch > anymore, but it will credits its author as acked/owned on the > parent report. On 2026-05-15 05:53, Bastien Guerry wrote: > I've tighten the rule so that a patch either has a [PATCH] or a > well-formatted patch (with git format-patch). > > So inline diffs and quick git diff > x.patch with no explicit > [PATCH] in the subject are not promoted as patch by BARK, they are > just code for comment in a thread. I like this approach! Certainly a lot better than another keyword. Between the two scenarios I think my original question is answered. Thanks for all your work on BARK, it’s been a pleasure to use. Best, -- 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
