Bastien Guerry <[email protected]> writes: > Morgan Smith <[email protected]> writes: > >> The BARK issue tracker doesn't seem to like that I replied to myself >> here to give a correction. > > As long as the In-Reply-To is in place, BARK will catch it. > > Delivery of emails to the GNU mailing lists is sometimes slow these > days, due to various problems. We have to wait for the BARK command > to arrive *via* the mailing list to find out if it has worked.
This is a very old bug so the issue wasn't timing. >From memory I belive this is what occured: I sent the mail. I had a local gcc'd copy which I then moved into another folder. Somewhere in that shenanigan's the message-id got completly mangled (this was also at a point in time where I was messing with gnus and icedove config stuff). Then I replied to this local mangled message. So the In-Reply-To was to a "non-existant" message-id. Basically, I think BARK is in the right and my setup was bad. Slightly related, but tangential question now: Marking this offshoot thread as "resolved" isn't quite right. In theory the correct thing to mark the offshoot thread as would be a "duplicate" or to use the command "Superseded-by: <msg-id>" (I think. Do correct me if wrong. This is your system, not mine :P). However, the superseded command is limited to maintainer use. So I guess I actually have two questions: Is the "Superseded-by: <msg-id>" part of the code working and ready for use? How come the "Superseded-by: <msg-id>" is limited to maintainers? In debbugs there is no limit on who can mark a bug as a duplicate. I haven't actually tested anything. I'm just going of off this document: https://codeberg.org/bzg/bark/src/branch/main/docs/bark-manual.org > Thanks for taking care of closing resolved bugs/patches! My pleasure! I was actually waiting to see the list's response before doing more as I was worried that I was creating clutter in the list.
