Re: Should maintainers receive copies of their own BTS mails?

I think, that's a good experiment:

<http://thread.gmane.org/gmane.linux.debian.user/297489>

First three guys are uncomfortable with current subscription system,
just as developers are.

* Don Armstrong (Tue, 24 Jul 2007 22:56:38 -0700)
>
[--]
>> BTS have this system, and you are bound to it, because so far i saw
>> no option in your propositions. Was it hard to implement or
>> maintain? Does it mean no other option exists and nobody willing to
>> try it?
>
> I'm still not sure what you're getting at; I'm open to other options,
> but I'm not particularly interested in writing a mailing list manager
> when there are mailing list managers which exist and do the job.
1.
>> i can prove, that there are other more productive and flexible
>> means.
>
> If you can come up with "more productive and flexible means" that
> satisfy my criterea, then feel free to recommend them.
2.
>> >> This isn't flexible (storage/dynamic management of GPG, etc).
>> >
>> > This objection makes no sense.
>> 
>> OK. Flexible is, when *anybody* can make things *easily*. Asking for
>> a ticket once and having bug id is easy, also no stupid spam.
>
> First off, what you're asking for here is ease of use, not
> flexibility.
3.

What i want to propose is:

* request subscription on reporting stage
  (reportbug dialog/conffile option)

* let users receive "Cc" list and suggest to do "group reply"

* manage it, e.g. s/$NO_CC_REQUEST_ADDRESS/$BUGXXXX_CC_LIST//

* suggest to make replies to existed messages (they are freely available)
  + thus making (managed) "Cc" propagate automatically
  + filtering spam by checking "in-reply-to" header

No man power from other side, i.e. d-a@l.d.o:
"[RFH] Listmaster team needs more manpower"

Easy and flexible(3).

> That said, ease of use and flexibility is precisely the point of doing
> things this way. You send a message once to the subscription system
> which says "Yerp; I'm a real person, subscribe me to lists" and then
> on subsequent messages, you set a header or pseudoheader or send mail
> to -subscribe for the bug, and you're automatically subscribed without
> responding to an ack message. If you decide you don't want to be
> subcribed, you send mail to -unsubcribe for the bug.
>
> What could be simipler for users of the BTS while still maintaining
> flexibility?

This is an idea, which wasn't implemented for more that two years,
right?

Maintaining pool of subscribers is the list manager you were talking
about in 1.

>> Everybody automaticaly in Cc list, until it is useful for *them*.
>
> There's no way for people to communicate that they no longer want to
> be Cc:'ed or that being Cc:'ed is counterproductive without having
> some sort of mailing list tracking it.

The "Cc" list includes bugid@b.d.o, obviously. That's how all info
stored in BR. Then, when things will calm down, no activity, messages
from local user's folders are likely to be archived in mbox. In case of
poke or ping, anybody is free to get last message from BR and reply to
it. This message will have *generated* current Cc list. Otherwise
ticket will be sent to confirm existence.

The ticket -- is a thing to have while posting to bugID without valid
"Cc" and (in this case) valid "in-reply-to" header. This is additional
logic, but this is certainly not list manager with that spamassasin all
over.
____