[Gnu-arch-users] Thread tracking for bugs

[Andrew Suffield]

As of now, some basic thread tracking is now performed on mailing list
posts, with the following behaviour:

List replies to [BUG] or [MERGE REQUEST] mails are appended to the
mbox for the relevant object.

[CLAIM], [REJECT] and [PUNT], with no arguments and as a reply to a
[BUG] or [MERGE REQUEST] mail, will operate on the object which they
are replying to. If it's a bug and is still in new/:

 [CLAIM] will note the claim, and process it when the bug has a number
         allocated.
 [PUNT] does nothing, unless the bug has already been claimed, in
        which case the claim is deleted.
 [REJECT] fails with an error message, because I haven't decided what
          to do with this yet. So don't use it (yet).


A mail is considered to be a list reply if it includes the Message-Id
of the *original* mail in its References field. With any reasonable
thread-aware MUA this should behave as expected. If you want to
*break* a thread, prune your References header to exclude the original
mail (but you can keep the immediate parent and In-Reply-To, so that
MUAs still see the thread). This will form a sub-thread which is not
considered to be a reply for the purposes of the above features.

Note that this is (deliberately) weaker than the threading behaviour
implemented by most MUAs. It is fairly unforgiving of offensive people
who always break threads. So don't.

In-Reply-To is ignored.

[Some of the above has not really been properly tested]

On a related note, I have now caught this mailing list delivering
mails out of order by a margin of at least several hours. If your
reply is delivered to bugs.gnuarch.org before the mail which you were
replying to, expect things to go confusingly wrong. There's nothing I
can do about that.

-- 
  .''`.  ** Debian GNU/Linux ** | Andrew Suffield
 : :' :  http://www.debian.org/ |
 `. `'                          |
   `-             -><-          |

signature.asc
Description: Digital signature