Bug#434149: Should maintainers receive copies of their own BTS mails?
On Sun, Jul 22, 2007 at 12:43:14AM +0200, Adeodato Simó [EMAIL PROTECTED] was heard to say: At the moment, maintainers do not receive a copy of the mail they send to bugs on their on packages. I only noticed this lately, but I'm told by Don that it's been like that for a while. Don also said that he doesn't have a strong opinion about that, so he's open to arguments either way. I think it makes sense to receive copies of such mail, the same way we receive our own mail to mail sent to lists.d.o. In particular, I think it's good so the whole set of mails are kept for reference together in the same mailbox. I agree -- it would make my offline work a lot simpler (currently I have to rely on the devscripts bug cache to get this information). Daniel
Bug#434149: Should maintainers receive copies of their own BTS mails?
Le dimanche 22 juillet 2007 à 22:18 +0200, Oleg Verych a écrit : 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? Mail-Followup-To isn't a standard of any kind. It isn't implemented in half of user agents. Even when they are explicitly requesting it? Then you can bet you will never reach them. 4. `Requesting' must be defined. Saying please CC me on your replies seems like a good start, but Don knowingly ignored it. 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. The BTS adds a Reply-To: [EMAIL PROTECTED], [EMAIL PROTECTED] to the mail sent to the maintainer. Respecting it is as easy as clicking reply in any user agent. This means Don, when replying to BTS emails, explicitly removes the submitter's address from the recipient list. 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. No, it's about common sense, which the BTS doesn't always follow. So, what about this. [snip] This sounds like an improvement, but I fail to see what it brings over the roundup behaviour (forging From: headers), which is the only one to deal with both broken MUAs and stupid users. -- .''`. : :' : We are debian.org. Lower your prices, surrender your code. `. `' We will add your hardware and software distinctiveness to `-our own. Resistance is futile.
Bug#434149: Should maintainers receive copies of their own BTS mails?
[] No, it's about common sense, which the BTS doesn't always follow. I tried to be approach that problems using technical means. Common sense isn't one. Agreement and flexible policy might be a solution. So, what about this. [snip] This sounds like an improvement, but I fail to see what it brings over the roundup behaviour (forging From: headers), which is the only one to deal with both broken MUAs and stupid users. Please elaborate on this. Especially why it can't be solved. Thanks. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#434149: Should maintainers receive copies of their own BTS mails?
Le dimanche 22 juillet 2007 à 00:43 +0200, Adeodato Simó a écrit : At the moment, maintainers do not receive a copy of the mail they send to bugs on their on packages. I only noticed this lately, but I'm told by Don that it's been like that for a while. Don also said that he doesn't have a strong opinion about that, so he's open to arguments either way. I think it makes sense to receive copies of such mail, the same way we receive our own mail to mail sent to lists.d.o. In particular, I think it's good so the whole set of mails are kept for reference together in the same mailbox. Any opinions for or against? The maintainer, *and* anyone having sent a mail to the bug should be CCed by default. The current rules force maintainers to search by hand all interested people in the bug log, which is insane when you have large numbers of bugs to handle. -- .''`. : :' : We are debian.org. Lower your prices, surrender your code. `. `' We will add your hardware and software distinctiveness to `-our own. Resistance is futile. signature.asc Description: Ceci est une partie de message numériquement signée
Bug#434149: Should maintainers receive copies of their own BTS mails?
On 2007-07-22 Frans Pop [EMAIL PROTECTED] wrote: On Sunday 22 July 2007 00:43, Adeodato Simó wrote: At the moment, maintainers do not receive a copy of the mail they send to bugs on their on packages. I only noticed this lately, but I'm told by Don that it's been like that for a while. If this is only in cases where Maintainer address == poster address, I have no objection. For all other cases (team maintained packages with mailing list in Maintainer field) and poster in Uploaders, it would AFAICT result in duplicate mails. Hello, Since the bts never sends messages to Uploaders but only to Maintainer there is no problem afaict. cu andreas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#434149: Should maintainers receive copies of their own BTS mails?
On Sun, 22 Jul 2007, Frans Pop wrote: On Sunday 22 July 2007 00:43, Adeodato Simó wrote: At the moment, maintainers do not receive a copy of the mail they send to bugs on their on packages. I only noticed this lately, but I'm told by Don that it's been like that for a while. If this is only in cases where Maintainer address == poster address, I have no objection. Right, that's how it works currently. Don Armstrong -- Herodotus says, Very few things happen at the right time, and the rest do not happen at all. The conscientious historian will correct these defects. -- Mark Twain _A Horse's Tail_ http://www.donarmstrong.com http://rzlab.ucr.edu
Bug#434149: Should maintainers receive copies of their own BTS mails?
On Sun, 22 Jul 2007, Josselin Mouette wrote: The maintainer, *and* anyone having sent a mail to the bug should be CCed by default. The current rules force maintainers to search by hand all interested people in the bug log, which is insane when you have large numbers of bugs to handle. People interested in the bug should subscribe to the bug. As a maintainer, you shouldn't bother emailing anyone but the bugnumber and possibly -submitter if you want to make sure that the submitter is also mailed. Don Armstrong -- Cheop's Law: Nothing ever gets built on schedule or within budget. -- Robert Heinlein _Time Enough For Love_ p242 http://www.donarmstrong.com http://rzlab.ucr.edu -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#434149: Should maintainers receive copies of their own BTS mails?
Le dimanche 22 juillet 2007 à 01:01 -0700, Don Armstrong a écrit : On Sun, 22 Jul 2007, Josselin Mouette wrote: The maintainer, *and* anyone having sent a mail to the bug should be CCed by default. The current rules force maintainers to search by hand all interested people in the bug log, which is insane when you have large numbers of bugs to handle. People interested in the bug should subscribe to the bug. As a maintainer, you shouldn't bother emailing anyone but the bugnumber and possibly -submitter if you want to make sure that the submitter is also mailed. Thanks for giving me the best proof that my request is valid: I have not received this email. The reply you sent only went to a single mailbox: the maintainer's. I had to go to the web interface to see it. You can't expect people to subscribe to a bug they are interested in. Bug reporters don't use the [EMAIL PROTECTED] address, they just send emails to bugs they are interested in. I don't even know what is the command to subscribe to the bug, and I don't want to use it anyway because it has no functional justification. When several people notice the same bug, it is often that they all write to the same bug after it being open, thanks to reportbug. Then, instead of blindly replying to the last email, I have to skim through all emails I have received on this topic to make up a list of recipients. This is all but efficient. Being CCed should be opt-out, not opt-in. Writing to the bug is proof you are interested in it. I would go even farther by suggesting to mimic roundup's behavior by forging From: headers, so that everyone always replies to [EMAIL PROTECTED] instead of whatever broken MUA can invent. -- .''`. : :' : We are debian.org. Lower your prices, surrender your code. `. `' We will add your hardware and software distinctiveness to `-our own. Resistance is futile. signature.asc Description: Ceci est une partie de message numériquement signée
Bug#434149: Should maintainers receive copies of their own BTS mails?
On Sun, 22 Jul 2007, Josselin Mouette wrote: Thanks for giving me the best proof that my request is valid: I have not received this email. The reply you sent only went to a single mailbox: the maintainer's. I had to go to the web interface to see it. If you're interested in the discussion around this bug, you should subscribe to it. You can't expect people to subscribe to a bug they are interested in. I think I've just done that, actually. You may disagree with the reasonableness of my expectations, but it's kind of silly to disagree with my ability to have them. Bug reporters don't use the [EMAIL PROTECTED] address, they just send emails to bugs they are interested in. I don't even know what is the command to subscribe to the bug, If you're not interested in learning how to subscribe to a bug (skip the next line now, because it's sending a message to [EMAIL PROTECTED]) then you're going to be rather unhappy, because I'm not going to make sending a message to all people who have ever sent a message to a bug the default. and I don't want to use it anyway because it has no functional justification. Its functional justification is that it handles determining who wants to receive messages related to a bug far better than anything I'm going to be willing to write in the near future. When several people notice the same bug, it is often that they all write to the same bug after it being open, thanks to reportbug. Then, instead of blindly replying to the last email, I have to skim through all emails I have received on this topic to make up a list of recipients. This is all but efficient. You shouldn't ever bother to do this. Just send messages to the bug number. I'm open to adding a header to messages so that you can easily indicate your desire to be subscribed to a bug, and I probably will do that as soon as it's possible to get the subcription information off of l.d.o. Don Armstrong -- UF: What's your favourite coffee blend? PD: Dark Crude with heavy water. You are understandink? If geiger counter does not click, the coffee, she is just not thick. http://www.donarmstrong.com http://rzlab.ucr.edu -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#434149: Should maintainers receive copies of their own BTS mails?
* Don Armstrong * Date: Sun, 22 Jul 2007 07:29:25 -0700 On Sun, 22 Jul 2007, Josselin Mouette wrote: Thanks for giving me the best proof that my request is valid: I have not received this email. The reply you sent only went to a single mailbox: the maintainer's. I had to go to the web interface to see it. If you're interested in the discussion around this bug, you should subscribe to it. 1. There's a new feature -- subscribing. pros: while done, it's easy to follow bug's messages cons: - handled by another party: l.d.o; unneeded complexity - subscribing have 2 stages with total 2/2 messages sent from both sides - unsubscribing -- the same [ skip subscribing part ] and I don't want to use it anyway because it has no functional justification. Its functional justification is that it handles determining who wants to receive messages related to a bug far better than anything I'm going to be willing to write in the near future. This is inconsistent with (see below) When several people notice the same bug, it is often that they all write to the same bug after it being open, thanks to reportbug. Then, instead of blindly replying to the last email, I have to skim through all emails I have received on this topic to make up a list of recipients. This is all but efficient. You shouldn't ever bother to do this. Just send messages to the bug number. this statement. Josselin replied to the bug number. That message got `reply-to' added by BTS: #v+ From: Josselin Mouette [EMAIL PROTECTED] Newsgroups: gmane.linux.debian.devel.bugs.general Subject: Bug#434149: Should maintainers receive copies of their own BTS mails? Date: Sun, 22 Jul 2007 15:47:55 +0200 Reply-To: Josselin Mouette [EMAIL PROTECTED], [EMAIL PROTECTED] #v- Yet Don did his reply against BTS rules: #v+ To: [EMAIL PROTECTED] Resent-From: Don Armstrong [EMAIL PROTECTED] Resent-To: debian-bugs-dist@lists.debian.org Resent-Cc: Debbugs developers [EMAIL PROTECTED] Resent-Date: Sun, 22 Jul 2007 14:33:06 + Resent-Message-ID: [EMAIL PROTECTED] X-Debian-PR-Message: report 434149 X-Debian-PR-Package: debbugs X-Debian-PR-Keywords: X-Debian-PR-Source: debbugs Mail-Followup-To: [EMAIL PROTECTED] #v- (no joss in `To' or `Cc') That's actually because Don have [EMAIL PROTECTED]' already. And additional noise thus is unneeded. That's why `Mail-Followup-To: [EMAIL PROTECTED]' appeared in reply. 2. Thus, here are two sides - BTS maintainer - package maintainer and they have different experience and goals, while trying to understand each other. I'm open to adding a header to messages so that you can easily indicate your desire to be subscribed to a bug, and I probably will do that as soon as it's possible to get the subcription information off of l.d.o. I think BTS's `reply-to' rules must not be implied, but based on some policy. That policy can be delivered from either `Cc', `Mail-Followup-To' or both. 3. Just keeping `Cc' can become annoying at some point or in the case if the interest was lost. Thus ordinary means of having a discussion thread are not apply. To sum up all three points: something must be designed to satisfy and increase effectiveness. ___ UF: What's your favourite coffee blend? PD: Dark Crude with heavy water. You are understandink? If geiger counter does not click, the coffee, she is just not thick. :) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#434149: Should maintainers receive copies of their own BTS mails?
On Sun, 22 Jul 2007, Oleg Verych wrote: * Don Armstrong * Date: Sun, 22 Jul 2007 07:29:25 -0700 If you're interested in the discussion around this bug, you should subscribe to it. 1. There's a new feature -- subscribing. It's actually not that new; Joachim and Pascal did the l.d.o side and I did the b.d.o side over two years ago now. pros: while done, it's easy to follow bug's messages cons: - handled by another party: l.d.o; unneeded complexity - subscribing have 2 stages with total 2/2 messages sent from both sides - unsubscribing -- the same This is a requirement for any subscription system, even if a message to a bug automatically causes you to be subscribed, as From is trivial to forge. I am interested in perhaps allowing people to confirm a subscription once, and then be able to subscribe to any bug using that same address without further confirmation (or perhaps with a GPG signature), but to date the code has not been written. 2. Thus, here are two sides - BTS maintainer - package maintainer and they have different experience and goals, while trying to understand each other. In this particular instance, I'm sitting in both positions, because this bug is against debbugs, and I am both a BTS maintainer as well as a maintainer of debbugs. I'm open to adding a header to messages so that you can easily indicate your desire to be subscribed to a bug, and I probably will do that as soon as it's possible to get the subcription information off of l.d.o. I think BTS's `reply-to' rules must not be implied, but based on some policy. That policy can be delivered from either `Cc', `Mail-Followup-To' or both. The reply-to: rules are actually kind of silly, and probably will be junked once its easier to subscribe to bugs without confirmation. Plus, it's always appropriate for people to cull the Cc: list. Don Armstrong -- Never underestimate the power of human stupidity. -- Robert Heinlein http://www.donarmstrong.com http://rzlab.ucr.edu -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#434149: Should maintainers receive copies of their own BTS mails?
Le dimanche 22 juillet 2007 à 07:29 -0700, Don Armstrong a écrit : If you're interested in the discussion around this bug, you should subscribe to it. I have already explained that I won't do it. You can't expect people to subscribe to a bug they are interested in. I think I've just done that, actually. You may disagree with the reasonableness of my expectations, but it's kind of silly to disagree with my ability to have them. You can play dumb if you want, but that doesn't make it a reasonable expectation. If you're not interested in learning how to subscribe to a bug (skip the next line now, because it's sending a message to [EMAIL PROTECTED]) then you're going to be rather unhappy, because I'm not going to make sending a message to all people who have ever sent a message to a bug the default. And until you do that, you just increase the workload for maintainers. There are 1600 bugs open on the GNOME packages; I'm not going to tell every bug submitter and contributor (for which there isn't even a sane way to make a list) to subscribe to the bug. All that leaves is the need to skip through the report before replying to any mail from the BTS. and I don't want to use it anyway because it has no functional justification. Its functional justification is that it handles determining who wants to receive messages related to a bug far better than anything I'm going to be willing to write in the near future. I'm not asking that there should be no management about who wants or not to receive messages. I'm asking this management to be opt-out rather than opt-in. 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. When several people notice the same bug, it is often that they all write to the same bug after it being open, thanks to reportbug. Then, instead of blindly replying to the last email, I have to skim through all emails I have received on this topic to make up a list of recipients. This is all but efficient. You shouldn't ever bother to do this. Just send messages to the bug number. 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. I'm open to adding a header to messages so that you can easily indicate your desire to be subscribed to a bug, and I probably will do that as soon as it's possible to get the subcription information off of l.d.o. * That may fix the issue for reportbug users, as support for this header could be added in it, but it doesn't change the general case. Listen, people write to [EMAIL PROTECTED], and: * They expect their email to go to the bug submitter; currently I have to resend it to the original submitter, which is a complete waste of time. * They expect to be recipients of new mails sent about this bug; currently this is done by hand. * Sorry, but I'm not going to reply to each bug submitter/contributor with please send an email with the blabla header set. A number of bug reporters wouldn't even know how to set a header. In case you haven't yet understood: please CC me on your replies, as the Reply-To indicates. -- .''`. : :' : We are debian.org. Lower your prices, surrender your code. `. `' We will add your hardware and software distinctiveness to `-our own. Resistance is futile. signature.asc Description: Ceci est une partie de message numériquement signée
Bug#434149: Should maintainers receive copies of their own BTS mails?
On Sun, 22 Jul 2007, Josselin Mouette wrote: Le dimanche 22 juillet 2007 à 07:29 -0700, Don Armstrong a écrit : If you're interested in the discussion around this bug, you should subscribe to it. I have already explained that I won't do it. Well, have fun following it otherwise. If you're not interested in learning how to subscribe to a bug (skip the next line now, because it's sending a message to [EMAIL PROTECTED]) then you're going to be rather unhappy, because I'm not going to make sending a message to all people who have ever sent a message to a bug the default. And until you do that, you just increase the workload for maintainers. There are 1600 bugs open on the GNOME packages; I'm not going to tell every bug submitter and contributor (for which there isn't even a sane way to make a list) to subscribe to the bug. All that leaves is the need to skip through the report before replying to any mail from the BTS. 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. 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. 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. 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. You shouldn't ever bother to do this. Just send messages to the bug number. 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. 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. I'm open to adding a header to messages so that you can easily indicate your desire to be subscribed to a bug, and I probably will do that as soon as it's possible to get the subcription information off of l.d.o. * That may fix the issue for reportbug users, as support for this header could be added in it, but it doesn't change the general case. Listen, people write to [EMAIL PROTECTED], and: * They expect their email to go to the bug submitter; currently I have to resend it to the original submitter, which is a complete waste of time. * They expect to be recipients of new mails sent about this bug; currently this is done by hand. Currently if you want your message to go to the submitter, you e-mail the bug number and -submitter; 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. Don Armstrong -- Americans can always be counted on to do the right thing, after they have exhausted all other possibilities. -- W. Churchill http://www.donarmstrong.com http://rzlab.ucr.edu
Bug#434149: Should maintainers receive copies of their own BTS mails?
clone 434149 -1 submitter -1 ! retitle -1 The recipient list management is insane thanks Le dimanche 22 juillet 2007 à 10:19 -0700, Don Armstrong a écrit : On Sun, 22 Jul 2007, Josselin Mouette wrote: Le dimanche 22 juillet 2007 à 07:29 -0700, Don Armstrong a écrit : If you're interested in the discussion around this bug, you should subscribe to it. I have already explained that I won't do it. Well, have fun following it otherwise. Oh, right. And until you do that, you just increase the workload for maintainers. There are 1600 bugs open on the GNOME packages; I'm not going to tell every bug submitter and contributor (for which there isn't even a sane way to make a list) to subscribe to the bug. All that leaves is the need to skip through the report before replying to any mail from the BTS. 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. 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. 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. 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. 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. 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. Even when they are explicitly requesting it? Then you can bet you will never reach them. 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. Currently if you want your message to go to the submitter, you e-mail the bug number and -submitter; 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. 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. -- .''`. : :' : We are debian.org. Lower your prices, surrender your code. `. `' We will add your hardware and software distinctiveness to `-our own. Resistance is futile. signature.asc Description: Ceci est une partie de message numériquement signée
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
Bug#434149: Should maintainers receive copies of their own BTS mails?
Package: debbugs Severity: wishlist At the moment, maintainers do not receive a copy of the mail they send to bugs on their on packages. I only noticed this lately, but I'm told by Don that it's been like that for a while. Don also said that he doesn't have a strong opinion about that, so he's open to arguments either way. I think it makes sense to receive copies of such mail, the same way we receive our own mail to mail sent to lists.d.o. In particular, I think it's good so the whole set of mails are kept for reference together in the same mailbox. Any opinions for or against? -- Adeodato Simó dato at net.com.org.es Debian Developer adeodato at debian.org Military justice is to justice what military music is to music. -- Groucho Marx
Bug#434149: Should maintainers receive copies of their own BTS mails?
On Sunday 22 July 2007 00:43, Adeodato Simó wrote: At the moment, maintainers do not receive a copy of the mail they send to bugs on their on packages. I only noticed this lately, but I'm told by Don that it's been like that for a while. If this is only in cases where Maintainer address == poster address, I have no objection. For all other cases (team maintained packages with mailing list in Maintainer field) and poster in Uploaders, it would AFAICT result in duplicate mails. Cheers, FJP pgpm5ijawAeuu.pgp Description: PGP signature
Bug#434149: Should maintainers receive copies of their own BTS mails?
On Sun, 2007-07-22 at 00:43 +0200, Adeodato Simó wrote: At the moment, maintainers do not receive a copy of the mail they send to bugs on their on packages. I only noticed this lately, but I'm told by Don that it's been like that for a while. Any opinions for or against? I prefer not to receive mail duplicates since I store outgoing mail in the same folder as incoming mail. This setting seems to be something different people will have different opinions on. I'm not sure how debbugs can support such settings, perhaps a [EMAIL PROTECTED] bot could be used to set these sort of things on a per-email address, similar to usertags, or the control bot could have another command added to set preferences. -- bye, pabs http://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Bug#434149: Should maintainers receive copies of their own BTS mails?
Adeodato Simó [EMAIL PROTECTED] writes: Package: debbugs Severity: wishlist At the moment, maintainers do not receive a copy of the mail they send to bugs on their on packages. I only noticed this lately, but I'm told by Don that it's been like that for a while. Don also said that he doesn't have a strong opinion about that, so he's open to arguments either way. I think it makes sense to receive copies of such mail, the same way we receive our own mail to mail sent to lists.d.o. In particular, I think it's good so the whole set of mails are kept for reference together in the same mailbox. Any opinions for or against? I think it would be good just so you see the mail was received. MfG Goswin
