Subject: Control system should notify original submitter
Date: Mon, 3 May 1999 16:04:29 +0300 (IDT)
Package: bugs.debian.org
Severity: Wishlist
Messages sent to [email protected] 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.
--
Brock Rozen [email protected]
Director of Technical Services (410) 602-1350
Project Genesis http://www.torah.org/
Package: bugs.debian.org
Version: N/A; reported 2002-08-26
Followup-For: Bug #37078
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.
-- System Information:
Debian Release: testing/unstable
Architecture: i386
Kernel: Linux laura 2.4.18 #1 Thu Jun 27 18:43:52 BST 2002 i686
Locale: LANG=en_UK, LC_CTYPE=C
On Tue, Jun 24, 2003 at 06:00:56PM +0300, Brock Rozen wrote:
> If I'm not mistaken, this behavior is now what happens as a default -- if
> so, please close this.
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,
--
Colin Watson [[email protected]]
On Tue, Jun 24, 2003 at 06:00:56PM +0300, Brock Rozen wrote:
> If I'm not mistaken, this behavior is now what happens as a default -- if
> so, please close this.
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...
--
2. That which causes joy or happiness.
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 [email protected]`. If it is the
default, anyone who cares to not receive mails can `echo
nosubscribe-newbugs |mail [email protected]`.
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.
--
Clear skies,
Justin
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.
--
Clear skies,
Justin
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).
--
Clear skies,
Justin
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 [email protected]". An additional sentence like "If
you wish to receive information about further updates on this problem,
please subscribe to [email protected]." would do the job, IMHO.
--
Christian
Subject: Re: Subscribe submitter to the per-bug subscription list by default
Date: Fri, 15 Nov 2019 14:10:03 -0800
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.
Debbugs is free software and licensed under the terms of the GNU General
Public License version 2. The current version can be obtained
from https://bugs.debian.org/debbugs-source/.