Bug#395054: closed by Don Armstrong [EMAIL PROTECTED] (Re: Bug#395054: Puzzle: my reopening a closed bug results in closing BTS reply, reportedly from me.)
reopen 395054 ! tag 395054 +wontfix thanks Around Wed, 08 Nov 2006 02:33:49 -0800 Don Armstrong wrote (caps added): Since the original issue behind this report has been resolved, and the secondary issue isn't one I think is a bug (OR AM INTERESTED IN fixing IF IT IS), I'm closing this bug. Well, if there is a bug, then you shouldn't close it based on whether or not it interests you. Fatigue or lack of interest is a poor reason for closing, rather you should close your interest in whatever topic bores you, and maybe do other things you like better. I really appreciate the time and help you've put into it, but worry that those misdirected URLs and hard to follow passages were indicators of overwork. Now for a troubleshooter or bug reporter, accidently or deliberately making mistakes can be a fine thing, because one often runs into new bugs or design flaws that way. But for the guy trying to fix things, one's own mistakes very seldom offer much in the way of extra benefits. By the original issue I think you meant bug #394813, the state of which is irrelevant to the validity of this bug. Aside from those points, I intend to let this bug sit a while and suggest you take a vacation from this, and maybe later I'll reread the thread and take a poke at it. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#395054: Puzzle: my reopening a closed bug results in closing BTS reply, reportedly from me.
On Fri, 3 Nov 2006 22:05:22 -0800 Don Armstrong [EMAIL PROTECTED] wrote: ...It's a question of how much logging and recording is enough, too much, or too little. I don't know if there's a general answer, but I know how to scratch where it itches... Again, the bug log keeps the original message, and the record of what it did when it parsed the message. The only thing that isn't kept is the output of parsing the entire message to control, because that can affect multiple bugs, and generally isn't terribly informative anyway. Pardon, I couldn't quite follow your second sentence above. Were you saying: That certain output is not publicly recorded because... 1) ...KEEPING it might affect multiple bugs. 2) ...it's prior effect can occasionally be difficult to automatically categorize. 3) ...something else? '1)' seems moot, since a web page copy of a sent email is not active code, and once stored affects nothing but our eyeballs. '2)' seems to support the opposite idea, since the larger the effect, the more interesting and record worthy its cause. As to whether a public html copy of a reopen confirmation email sent to the reopener is tremendously informative, I agree it's not. The data would only needed once in blue moon, but when needed could be a little bit useful. It's like a 'typo' bug. Most of the time nothing very bad happens if a typo remains, yet things are slightly better when it's fixed. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#395054: Puzzle: my reopening a closed bug results in closing BTS reply, reportedly from me.
On Thu, 2 Nov 2006 19:10:13 -0800 Don Armstrong [EMAIL PROTECTED] wrote: It seems like a useful message that belongs in the bug log. If that's the only problem, then perhaps this bug should be changed to to a 'wishlist' bug and retitled Improvement: add reopen email control message to BTS log. The effect of the control message is put there, as well as the original message to control that caused the bug to be reopened. The parsing of the message isn't included because it's not applicable to the bug log. If an absence of records regarding some automated function confuses users, (me for one), then is that not a sort of interface bug? While I'm still not sure if I missed an reopen acknowledgement email, it's probable that eventually somebody is going to miss such an email, and that's when a copy on the BTS would be helpful. What's not applicable in this context begs the question of what the public BTS is for. Mainly the BTS is for publicly describing bugs. But without the record keeping and event logging the BTS would be less reliable. It's a question of how much logging and recording is enough, too much, or too little. I don't know if there's a general answer, but I know how to scratch where it itches... -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#395054: Puzzle: my reopening a closed bug results in closing BTS reply, reportedly from me.
On Sat, 04 Nov 2006, A. Costa wrote: On Thu, 2 Nov 2006 19:10:13 -0800 Don Armstrong [EMAIL PROTECTED] wrote: It seems like a useful message that belongs in the bug log. If that's the only problem, then perhaps this bug should be changed to to a 'wishlist' bug and retitled Improvement: add reopen email control message to BTS log. The effect of the control message is put there, as well as the original message to control that caused the bug to be reopened. The parsing of the message isn't included because it's not applicable to the bug log. If an absence of records regarding some automated function confuses users, (me for one), then is that not a sort of interface bug? The record is what was reported; all that gets recorded is the actual action that was taken to the bug. While I'm still not sure if I missed an reopen acknowledgement email, it's probable that eventually somebody is going to miss such an email, and that's when a copy on the BTS would be helpful. If you miss it, you can always check the BTS to see if the comands that you attempted to run had the desired effect, coupled with your original email. What's not applicable in this context begs the question of what the public BTS is for. Mainly the BTS is for publicly describing bugs. But without the record keeping and event logging the BTS would be less reliable. It's a question of how much logging and recording is enough, too much, or too little. I don't know if there's a general answer, but I know how to scratch where it itches... Again, the bug log keeps the original message, and the record of what it did when it parsed the message. The only thing that isn't kept is the output of parsing the entire message to control, because that can affect multiple bugs, and generally isn't terribly informative anyway. Don Armstrong -- People selling drug paraphernalia ... are as much a part of drug trafficking as silencers are a part of criminal homicide. -- John Brown, DEA Chief http://www.donarmstrong.com http://rzlab.ucr.edu -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#395054: Puzzle: my reopening a closed bug results in closing BTS reply, reportedly from me.
On Thu, 02 Nov 2006, A. Costa wrote: On Fri, 27 Oct 2006 13:57:08 -0700 Don Armstrong [EMAIL PROTECTED] wrote: The message above *is* the reopen indication; you got sent an ack from parsing that control mail. That's confusing since that URL points to this text: It should have been #11; The ack gets sent to you, not to the bug log. It seems like a useful message that belongs in the bug log. If that's the only problem, then perhaps this bug should be changed to to a 'wishlist' bug and retitled Improvement: add reopen email control message to BTS log. The effect of the control message is put there, as well as the original message to control that caused the bug to be reopened. The parsing of the message isn't included because it's not applicable to the bug log. ...2) When a bug is reopened, the BTS would the user a clear acknowledgement, -- prior to and separate from any closing message. This is done. If you didn't see it, you either missed it or your mail system ate it. Maybe; the BTS usually sends such messages. But I try hard not to miss mail, and would like to test that. Any scratch pad facilities on the BTS, like Usenet's 'alt.test'? Nope; there was a wishlist bug for them, but since messages there would be also sent to the various distribution lists, it's not appropriate. Don Armstrong -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot http://www.donarmstrong.com http://rzlab.ucr.edu -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#395054: Puzzle: my reopening a closed bug results in closing BTS reply, reportedly from me.
On Fri, 27 Oct 2006 13:57:08 -0700 Don Armstrong [EMAIL PROTECTED] wrote: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=394813#13 I'd received that and also seen it on the BTS, but as you say there's no reopen 'ack', just a you closed it message. The message above *is* the reopen indication; you got sent an ack from parsing that control mail. That's confusing since that URL points to this text: Reply sent to [EMAIL PROTECTED]: You have taken responsibility. _Full_text_ and rfc822 format available. Ah well. Eureka, two lines before that URL it says: % wget -o /dev/null --output-document=- http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=394813; | html2text -ascii -nobs | grep -in -A 1 -m 1 reopened 118:Bug reopened, originator set to [EMAIL PROTECTED] Request was from A. Costa 119-[EMAIL PROTECTED] to [EMAIL PROTECTED] Full_text and rfc822_format (BTW, is there a text-based 'URLgrep' command?) Some form of distinct reopen 'ack' would be less confusing. The ack gets sent to you, not to the bug log. It seems like a useful message that belongs in the bug log. If that's the only problem, then perhaps this bug should be changed to to a 'wishlist' bug and retitled Improvement: add reopen email control message to BTS log. ...2) When a bug is reopened, the BTS would the user a clear acknowledgement, -- prior to and separate from any closing message. This is done. If you didn't see it, you either missed it or your mail system ate it. Maybe; the BTS usually sends such messages. But I try hard not to miss mail, and would like to test that. Any scratch pad facilities on the BTS, like Usenet's 'alt.test'? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#395054: Puzzle: my reopening a closed bug results in closing BTS reply, reportedly from me.
On Thu, 26 Oct 2006 22:58:18 -0700 Don Armstrong [EMAIL PROTECTED] wrote: If I'd missed an emailed reopen 'ack', it should be on the BTS page for #394813 somewhere... The acks don't show up on the BTS; all you see is the effect of the message to control, which is there: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=394813#13 I'd received that and also seen it on the BTS, but as you say there's no reopen 'ack', just a you closed it message. Some form of distinct reopen 'ack' would be less confusing. Thanks very much for explaining how there is no reopen 'ack'. I'd been wondering whether I'd missed mail or the BTS had mail troubles. Perhaps we now agree as to some particulars: the mail on both ends seems to be working OK, and the confusion (of at least one user) stems from the BTS behavior itself. To recap, a suggested fix would be one of these: 1) Make the BTS smarter about emails. A 'reopen' and a '-done' in one message could be parsed, and the BTS would consider these contradictory orders, refuse to do either, then email the user an error message explaining how one can't open and close a bug simultaneously. 2) When a bug is reopened, the BTS would the user a clear acknowledgement, -- prior to and separate from any closing message. 3) When the BTS gets a reopen/close message, it processes it, and the user is sent a message that it reopened/closed it (that is two messages in one email instead of two separate emails). A note on '1)': if the BTS 'control' and '-done' messages are sent to two different places, the new algorithm would need to be something almost multi-threaded like: A) Thread for '-done' server 1) check for '-done' and 'control' in header a) check for 'reopen' yes) contradiction. Do nothing, leave it to 'control'. B) Thread for 'control' 1) check for '-done' and 'control' in header a) check for 'reopen' yes) contradiction. Email user error message. HTH... -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#395054: Puzzle: my reopening a closed bug results in closing BTS reply, reportedly from me.
On Fri, 27 Oct 2006, A. Costa wrote: On Thu, 26 Oct 2006 22:58:18 -0700 Don Armstrong [EMAIL PROTECTED] wrote: If I'd missed an emailed reopen 'ack', it should be on the BTS page for #394813 somewhere... The acks don't show up on the BTS; all you see is the effect of the message to control, which is there: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=394813#13 I'd received that and also seen it on the BTS, but as you say there's no reopen 'ack', just a you closed it message. The message above *is* the reopen indication; you got sent an ack from parsing that control mail. Some form of distinct reopen 'ack' would be less confusing. The ack gets sent to you, not to the bug log. All the bug log gets is the indication that the bug was reopened by your control message. To recap, a suggested fix would be one of these: 1) Make the BTS smarter about emails. A 'reopen' and a '-done' in one message could be parsed, and the BTS would consider these contradictory orders, refuse to do either, then email the user an error message explaining how one can't open and close a bug simultaneously. That's not going to happen. Because the messages are two separate ones, one to -done, and one to control, the first message to control actually opens the bug. It has no idea whether a message actually was sent to -done or if it's just the To: headers lying. The control message gets handled first, reopening the bug. Then the done messages get handled, which close the bug. This is perfectly consistent. 2) When a bug is reopened, the BTS would the user a clear acknowledgement, -- prior to and separate from any closing message. This is done. If you didn't see it, you either missed it or your mail system ate it. 3) When the BTS gets a reopen/close message, it processes it, and the user is sent a message that it reopened/closed it (that is two messages in one email instead of two separate emails). They're separate parsers; they have to be done separately. Don Armstrong -- Nothing is as inevitable as a mistake whose time has come. -- Tussman's Law http://www.donarmstrong.com http://rzlab.ucr.edu -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#395054: Puzzle: my reopening a closed bug results in closing BTS reply, reportedly from me.
Package: bugs.debian.org Severity: important A bug gets closed. I reopen it, or attempt to. The BTS replies with a message claiming that it was closed by me. For full details, see: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=394813 This is doubly confusing: 1) I did not close it. 2) It should be impossible for a bug that's closed to be closed again. Hope this helps... -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/dash Kernel: Linux 2.6.16-2-686 Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) (ignored: LC_ALL set to C) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
