20-07-2007, Don Armstrong <[EMAIL PROTECTED]> пишет: > On Fri, 20 Jul 2007, Oleg Verych wrote: >> Note, that i'm talking about forwarded messages. > > There's no real difference. Messages come into the bts, are stored. > Messages go out of the bts, and are also stored. The same message goes > to -dist, the maintainer, the pts, and anyone who is subscribed to the > bug.
-dist is here and i'm anyone who can actually help with things i know. >> OK, let me show how it looks: >> >> #433834: curl: Should run tests on hurd-i386 either >> ->33836: nautilus: No documentation on which volumen devices icons are shown >> and >> #433837: nautilus: Unusable "unmount volume" option >> #432614: dvgrab: uses unsupported isochronous request types >> #433285: found 433285 in 0.4.0b-10, closing 433285 >> >> See last one? It's without context, while previous have one. >> And this is currenty depends: or it's generated by reportbug, or pkg >> name added by hand by developer who answered. I'm asking about making >> all them look same. > > The all look the same; the only thing that debbugs adds is the #NNN:; > every other bit is the subject of the message which was sent to bug > NNN or affected bug NNN. > > 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, >> Second thing's threading (combining above): >> >> #433834: curl: Should run tests on hurd-i386 either >> ->33836: nautilus: No documentation on which volumen devices icons are shown >> and >> #433837: nautilus: Unusable "unmount volume" option >> `| (empty means same subject) >> `- #433837: nautilus: found XYZ in 0.4.0b-10, closing XYY >> `- #433837: nautilus: Done.... thus i've added pkg name here. >> That's what i'm talking about. > > That's not reasonable either, because you're assuming a message is in > reply to another message, when it isn't neccessarily a reply. > > Making it easier for people to include the appropriate References: and > In-Reply-To: is the way forward, which will resolve most cases of this > for actual messages. I'm willing to apply appropriate patches for > that, but I'm not planning on faking References: or In-Reply-To: for > the above reasons. If not "References" i'm will be OK with "X-Resent-References" or whatever else. This kind of thing is much easy to implement and maintain, than all that subscribe/unsubscribe kind of things. Thanks for conversation. ____ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
