Hi Jacob, > I’m fine sticking to one label in the subject! My concerns are more > about the automatic mechanism for recognizing patches.
Well, actually, your input was very useful and made me think a lot. BARK was trying to be clever about detecting patches in many contexts, not just depending on the subject-prefix "[PATCH]" but also on presence of attachments, promoting an email-with-a-patch within a report-thread as a standalone patch... which leads to the problems you reported. Basically: not all patches are equal and probably many of them are just quick attempts at showing a possibility. Still, it's good to know what reports (bug or requests) have patches. So this led me to implement a new approach that I'll summarise: - 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. - 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. Here is the result of parsing the ML since 2020 with these rules: https://tracker.orgmode.org/next/ Within all reports (including closed ones), you'll see: - -1156 patches: because patches in threads are ignored - +64 bugs: because patches in threads don't replace bug reports - +23 requests: because patches in threads don't replace request reports - Same number (30) of announcements, untouched by the change What do you think about the change? Can you explore the new version at https://tracker.orgmode.org/next/ and see if it seems more useful? It should be more aligned with your proposal to not consider all patches equally important. Ihor's feedback, as well as that of other contributors, is welcome, of course. Thanks! -- Bastien
