Bug#434149: Should maintainers receive copies of their own BTS mails?
Thanks for maintaining BTS, Don!
[]
>> I'm not averse to including information in the ACK message on how to
>> subscribe to the bug so submitters and people who message the bug can
>> keep up; it's one of the things I'm going to do as I transition to
>> templates for the messages that the BTS sends out.
>
> I can't wait to see that. "Thanks for submitting this bug report. If you
> ever want to receive feedback on it, please send two other emails."
> Hahaha. Awesome.
1. Anti-subscribing point about complicated process.
>> > Currently bug subscribing serves as a justification to the insane
>> > recipient management of debbugs. "Well, you can just subscribe to
>> > the bug" is an excuse for everything. Sorry, but things don't work
>> > like that. You need to make the *default* behavior obvious. Expert
>> > users always find their way if it is properly documented, but novice
>> > users won't even try to find a documentation.
>>=20
>> The point is that most novice users don't care about what's going on
>> in a bug report until such a point when the bug is resolved; they just
>> want to submit a bug and get told when it's fixed.
>>=20
This assertion have no proof, sorry.
2. Nothing prevents reportbug from including one request for submitter
about "being Cc's on bug activity". Thus bug will have such information
explicitly.
(semantics of the `Cc', i.e. subscription, i propose, will follow)
>> Users who are at a higher level should at least be capable of reading
>> the ack message and following instructions in it as indicated above.
>
> I don't know on what packages you are working, but on mine, things don't
> work like that.
>
> One users sends a report; the maintainer ask details. In the meantime,
> another user adds a comment to this report; the maintainer asks other
> details and adds the original submitter to the CC list. One of them has
> a relevant comment, but the other doesn't receive his mail, so the
> maintainer has to ask a new question to the other. That's for only two
> people affected. With more people, the maintainer's workload increases
> exponentially.
Yes. Such things are usual in projects involving many users.
3. Many users, OTOH, may have "more noise"/"huge developer's mail
backlog" issues. I have seen similar things in LKML, that's why i'm
trying to help. Adding more flexability is main goal of mine.
> How in the world is the BTS, which is configured with only one way of
> dealing with bugs in mind, supposed to deal with this bug profile?
> According to your behavior in this bug log your reply is "ignore people
> who don't subscribe to the bug". Sorry, that may decrease significantly
> the workload, but that's not how I want to deal with users.
>
>> > Sorry, but unlike you in this discussion, I expect bug reporters and
>> > contributors to receive the messages I send. Otherwise, I can as well
>> > read a book or watch TV, it will have the same result for them.
>>=20
>> If I want the bug reporter to see the message, I send it to
>> -submitter, otherwise I expect interested parties to have subscribed
>> to the bug or otherwise be keeping track of it. It's the same reason
>> why I don't Cc: people who post to mailing lists.
... unless they have mail-followup-to setup, isn't it?
> Even when they are explicitly requesting it? Then you can bet you will
> never reach them.
4. `Requesting' must be defined. The `reply-to' in the rfc2822 while "not
addressed here" have one statement:
"""
When the "Reply-To:" field is present, it indicates the mailbox(es) to
which the author of the message suggests that replies be sent.
"""
So it's a weak request anyway.
> One of the few good things with Bugzilla is, when you add a comment, you
> get added to the CC list *unless you click the appropriate checkbox*.
> This is straightforward and absolutely obvious for users. I don't
> understand what could be wrong in mimicking it.
It's all about convention and relevant policy.
5. If `reply-to' is "silly", that all must be revisited in a very careful
way.
(: "e-mail is rocket science"
<http://permalink.gmane.org/gmane.linux.debian.devel.exim4.user/1103>)
>> Currently if you want your message to go to the submitter, you e-mail
>> the bug number and -submitter;=20
>
> What if I want to reach the submitter and anyone who added comments?
> This is the most common case and it is not handled. If I add to that the
> fact there is no functionality for reaching submitters of merged
> reports, the BTS behaves merely as an email archive, not as an issue
> tracking tool.
6. Not all, but all still interested and not bouncing.
>> I'm not particularly happy about how
>> -submitter works currently, but the solution that I enact is (most
>> likely) going to involve tighter integration with the bug subscription
>> system, rather than less.
>
> Good. Then, please make it opt-out than opt-in, add a -all address which
> includes both submitter and subscribers, and this will be fine.
So, what about this.
1,2: requesting submitter being in bug's information flow.
[see bottom on spam]
Instead of ACK message, BTS sends copy of report back to
submitter as well as to maintainers/relevant mailing list.
Message have no `reply-to', but `Cc' list with bug's address and
submitter's in case of positive reply.
This implies, that users know how and why reply-to-all (group
reply) works. Otherwise it's still `reply-to' as of today to
force MUAs to do the job.
3: case of additional replies from others.
3.1 reply was done without using original e-mail. Thus message
have no threading headers (in-reply-to, references), `Cc'
information is lost
3.2 unless this header is present and valid. Valid means it has
bug's current `Cc' list.
[see bottom on spam]
BTS resends copies to current `Cc' list with `Cc', thread headers
added/changed appropriately. `Subject' may be used to create
correct choice in threading. In this case `Cc' of last matching
subject is used, not current one.
(Adding `reply-to' now is also making message not original, as
opposed to Resent-* headers).
3.3 control message generated using devscripts
i would like this messages would be threaded also;
only BTS's ack is resent to current `Cc' list.
3,4: case of reply done using original mbox/rfc822 message. If 3 was
honored previously, no additional work is needed.
5,6: managing current `Cc' list.
If somebody cares about not being in flow any more (and this is
important, because there's a motivation) message to
<bug#-no-more-cc@b.d.o> must be sent, thus removing address in
`From' header from the current `Cc'.
similarly adding somebody is done by <bug#-add-me@b.d.o>, in case
person is just willing to listen, but so far have nothing to say
(fixing 1)
While re-sending BTS can figure out bouncing addresses, like ML services
usually do, thus cleaning up current `Cc' list.
So, as you see, this is combining always-group-reply, like in LKML,
glibc, gcc lists with distributing load and more advanced management
in the BTS.
-*-
Also, i want to mention here my idea about spam fighting with tickets,
posted to d-d. In bug submitting process and replying without using
original message there is one issue, that prevents message to valid
non spam one.
I'm proposing using a ticket -- message sent to submitter or commenter
as a reply to ticket request. Replying to that message includes
in-reply-to header which can be used as access granting token.
____
Reply to: