Messages sent to control@bugs.debian.org that modify the bug report (either close, change severity, package, etc) should be CC'd (the results, I guess) to the submitter so that he can keep track of his bug and if somebody changes something on it.
I would go further and say that all messages that are entered into the BTS, via whatever mechanism, for a particular bug, should be sent to the submitter of that bug. Many times I have looked at a bug's record on the web, to find that the packager has entered comments on a bug I reported, which have not found their way to me (OK, it is true that they should be more careful and read the docs., but the behaviour is non-obvious). Regards, Andrew.
If I'm not mistaken, this behavior is now what happens as a default -- if so, please close this. Thanks,
Sorry, you're mistaken. Apart from the 'close' and 'submitter' commands which have the side-effect of sending mail to the submitter, the results of control messages currently only go to the sender, the maintainer, and anyone subscribed to the package(s) in question via the PTS. This bug is a special case of generally subscribing to bugs, namely #38116 et al. Cheers,
Only for closing and changing submitter -- not for changing severity, reassigning etc. I'm not sure if we'll ever want to implement all that by default...
Back in 2002, Andrew Ferrier wrote, on bug #37078 "Control system should notify original submitter": "I would go further and say that all messages that are entered into the BTS, via whatever mechanism, for a particular bug, should be sent to the submitter of that bug." This would be helpful, and should be the default BTS behavior, maybe with a toggle to turn it off. I've posted a buglist message or two that should have been shorter, had I only known others had earlier posted something to the same effect. At present to find out if there's new stuff a user can poll the bug list web page, leading to an arithmetic progression of bandwidth waste, to say nothing of man-hours. You'd have to download 'n' messages, where 'n' is how many messages there are today, each and every time before you post. The minimum total messages a user who polls would download over the course of a bug is a triangular number, some variant of n(n+1)/2, depending on the posting frequency. Example, I post a bug and resolve to be thorough in checking for replies. Day 1: post bug. Receive confusing reply from Erehwonian maintainer. Day 2: check web list to see if anyone replied to maintainer. No. I've just DL'd the text of 2 messages I already have. Then I write a reply to maintainer. Before finishing, the phone rings, business calls me away. Day 3: finish writing reply to maintainer. Now I can post it, but first I check the web list to see if anyone else has posted. No. So I've now DL'd the text of 2 messages I already have, twice; total redundant message DL's 4. I post my message. Day 4: maintainer, still confused, replies. Check list, nothing new, but I had to DL 4 messages to find out. Total redundant message DL's 8. Write reply slowly as to eliminate confusing parts. Day 5: double check reply, it's ready. Check list, nothing new, DL 4 messages, Tot. Red. Mess.'s 12. Send reply. And so on. If a reply takes much time to write, you have to check the list twice, once before you write it, and then before you post it. When bugs turn into debates, bug lists can exceed 100K, at which point most posters are unlikely to poll the web list, so they miss messages relevent to them, and the debate collapses from collective fatigue and amnesia. Though fine for short and simple bugs, the present web-based system doesn't scale well. See also: #38116 bugs.debian.org: one should be able to subscribe to a particular bug http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=38116 ...and a netiquette maxim: Read all follow-ups and don't repeat what has already been said http://www.use-net.ch/netiquette_engl.html#followup3 Note: I'm cc'ing this post to some recent posters on the topic. Apologies if this is unwelcome.
I suggest the following web or email based implementation. Submitters are subscribed to their new bugs if they so choose; there should be an 'subscribe-newbugs' request bot command. Bug triagers are subscribed to bugs on which they comment if they so choose; there should be an 'subscribe-bugshelp' request bot command. I make no claim as to whether the default should be for either submitters triagers to be subscribed; it doesn't seem to make much of a difference. Once this is implemented, if the default is not for subscription, then everyone who cares will immediately `echo subscribe-newbugs |mail request@bugs.debian.org`. If it is the default, anyone who cares to not receive mails can `echo nosubscribe-newbugs |mail request@bugs.debian.org`. Same thing for [no]subscribe-bugshelp. Of course, if the default is for subscription for "bugshelp", then so should be the default for submission, and if the default is for no subscription on submission, then so should be the default for "bugshelp". There should also be an "mybugshelp" request bot command, which returns a list of all bugs on which the submitter has commented. And an "subscribe-allmysubmissions" request command, which subscribes to all bugs from a given submitter, and an "subscribe-allmyhelp" which subscribes to all bugs on which someone has commented. Of course there needs to be unsubscribe, also, and confirmation emails.
I'm using the included procmail file for subscribing myself to all bugs for which I am the submitter, or on which I have commented. I see 4 problems: It is implemented on the clientside, and it would IMHO be better if debbugs implemented it (but that is known:). It doesn't track control bot messages. So if I tag a bug, but don't otherwise comment on it, I won't get subscribed. I want to be able to do so. It doesn't subscribe me to bugs that I've commented on in the past. This could be solved by a solution to #293166: bug.debian.org: "Provide list of bugs on which I have commented". It might subscribe me multiple times. I don't know if the BTS handles this gracefully. In the worst case, I will get subscribed to a bug for each time I comment on it. In the best case, the BTS will ignore the initial "subscribe" message from addresses which are already subscribed (or, in the case of an subscribe-this-*other*-address command, that the other address is subscribed), and this will reduce mail traffic. This can probably be fixed by adding an 'grep -w $MATCH &&' before sending the messages.
Included is a second-attempt procmail config file which also handles control bot messages.
Third attempt, which includes a necessary "To:" condition which avoids being subscribed to packages and its newly submitted bugs, (which isn't so much a problem except when other people submit lots of bugs).
Hi! AFAIU I don't get automatically subscribed to bugs I submit. Is there anything holding back this change? I was unable to find any reason for this not going in in the above discussion. Regards //Johan
Hi, simply updating the mail send out when acknowledging a newly reported bug to additionally mention that one has to subscribe to receive any updates would help a lot already, I think. Currently that mail only mentions "If you wish to submit further information on this problem, please send it to xyz@bugs.debian.org". An additional sentence like "If you wish to receive information about further updates on this problem, please subscribe to xyz-subscribe@bugs.debian.org." would do the job, IMHO.
I would like to revive this issue. I feel strongly that submitters should automatically be subscribed to their reports. It is often very important that users see responses to their reports, and they shouldn't have to go through extra steps to get the updates. Furthermore, I see no value in allowing users to be able to "fire and forget" bug reports. I have never not wanted to be subscribed to a report that I create, and I can't ever imagine that I would. If I really didn't want to receive updates then I would be fine having to take an extra step to unsubscribe. jamie.