1. Adding pkg name to forwarded messages: >> > Control transcripts can affect hundreds or thousands of bugs, so >> > there's no way that all of the packages will ever be listed in the >> > subject. >> >> But NNN is unique for one particular pkg, > > It's actually not. There's no limit to how many packages a bug can be > assigned to.
Big corner cases? Well, i have plenty of imagination how to encode it in place on otherwise one pkg name. 2. Threading, message-ids: >> If not "References" i'm will be OK with "X-Resent-References" or >> whatever else. > > You already get the equivalent of what you're asking for by separating > on Subject: #NNNN and ordering by date. That's sorting, not threading. Latter means collapsed subject line with number of replies shown; slrn highlights your name, thus by seeing it with any number brings you on business immediately. Checking and reading successive #ZYX is a different thing. >> This kind of thing is much easy to implement and maintain, than all >> that subscribe/unsubscribe kind of things. > > Heh. It's actually not; requiring every message that is sent to the > BTS to parse the logfile for information on the previous messages is > definetly non-trivial. Again extremes. Why every? Currently these are automatic generated (control messages) and messages without in-reply-to. The latter is a very strange, WRT information available in bts. Why people can't download mbox formatted message and reply without any problems, i.e. `mutt -f`? BTW, good policy to get rid of all spam, or it's not? About non-triviality. I've got impression from using web interface, that all messages are stored in associative form, i.e access is fast, bug ID is a key. ____ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
