Re: forwarding bugs upstream - opt-in, delayed, automated
On Fri, 16 Sep 2011, Lars Wirzenius wrote: On Thu, Sep 15, 2011 at 06:47:52PM -0700, Don Armstrong wrote: I am looking for a set of perl modules which can handle being fed mail and managing a subscription list in response to that mail while also allowing for subscriptions/unsubscriptions from an external interface. Such a thing may not exist at all, but if it does, I would rather like to avoid reinventing the wheel if at all possible. bugs.debian.net uses, or at least used to use, Enemies of Carlotta already for subscribing to bugs. Perhaps that could be used for this as well? Not easily (at least, not without making the integration much tighter.) Basically, it should be possible to subscribe to any bug for which you can currently describe a limit; the full set of these is so large that it would be wasteful to generate all of the mails for them, so the BTS would need to know which limits people actually cared about, and only generate the mails for them. [That part isn't too hard, but properly managing the bounces etc. needs to be done... (and frankly, almost every mail that the BTS generated should probably go through this mechanism with proper bounce processing, etc.x] Don Armstrong -- We want 6. 6 is the 1. -- The Prisoner (2009 Miniseries) _Checkmate_ http://www.donarmstrong.com http://rzlab.ucr.edu -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110919004140.gj10...@teltox.donarmstrong.com
Re: forwarding bugs upstream - opt-in, delayed, automated
On Thu, Sep 15, 2011 at 06:47:52PM -0700, Don Armstrong wrote: I am looking for a set of perl modules which can handle being fed mail and managing a subscription list in response to that mail while also allowing for subscriptions/unsubscriptions from an external interface. Such a thing may not exist at all, but if it does, I would rather like to avoid reinventing the wheel if at all possible. bugs.debian.net uses, or at least used to use, Enemies of Carlotta already for subscribing to bugs. Perhaps that could be used for this as well? -- Freedom-based blog/wiki/web hosting: http://www.branchable.com/ signature.asc Description: Digital signature
Re: forwarding bugs upstream - opt-in, delayed, automated
On Sep 15, 2011, at 06:47 PM, Don Armstrong wrote: On Wed, 14 Sep 2011, Barry Warsaw wrote: Can you provide a bit more detail on this? I am looking for a set of perl modules which can handle being fed mail and managing a subscription list in response to that mail while also allowing for subscriptions/unsubscriptions from an external interface. Such a thing may not exist at all, but if it does, I would rather like to avoid reinventing the wheel if at all possible. Thanks. I don't know what you need but maybe it's something that Mailman 3 could help with? Mailman3 isn't finished and is a complete system for dealing with standard mailing lists which don't get created or deleted on the fly. I can't/won't help with the Perl bits, and don't want to clutter up this mailing list with discussions of MM3, but if you're interested in exploring possibilities or influencing its feature set, please contact me off-list. Cheers, -Barry signature.asc Description: PGP signature
Re: forwarding bugs upstream - opt-in, delayed, automated
On Wed, 14 Sep 2011, Barry Warsaw wrote: On Sep 13, 2011, at 04:48 PM, Don Armstrong wrote: The main thing that is blocking me from implementing it currently is a set of perl modules which can handle the hard bit of managing a mailing list correctly so I don't have to write them from scratch. Can you provide a bit more detail on this? I am looking for a set of perl modules which can handle being fed mail and managing a subscription list in response to that mail while also allowing for subscriptions/unsubscriptions from an external interface. Such a thing may not exist at all, but if it does, I would rather like to avoid reinventing the wheel if at all possible. I don't know what you need but maybe it's something that Mailman 3 could help with? Mailman3 isn't finished and is a complete system for dealing with standard mailing lists which don't get created or deleted on the fly. Don Armstrong -- Sentenced to two years hard labor (for sodomy), Oscar Wilde stood handcuffed in driving rain waiting for transport to prison. If this is the way Queen Victoria treats her prisoners, he remarked, she doesn't deserve to have any. http://www.donarmstrong.com http://rzlab.ucr.edu -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110916014752.gh10...@teltox.donarmstrong.com
Re: forwarding bugs upstream - opt-in, delayed, automated
Hi Stefano (et al.)!
Stefano's post contains a fair assessment of our discussion. However I
would like to state in my own words the basic idea. I'll also provide
a couple of ideas of implementation details.
the problem
--
Often issues that ought to be sent upstream, aren't.
This is *the worst thing* in my view.
I saw real bug reports years old, with no activity, that I could have
easily fixed.
The most brain-dead solution of sending all reports upstream could be
viewed as spamming,
for 2 reasons:
* it wasn't requested
* it contains stuff (about packaging issues, etc) of no interest upstream
status quo
-
*If upstream is aware of the option*, they can choose to be advised of
all bugs or none.
This gives upstream some control, and protects downstream from
accusations of spamming, since upstream has to subscribe to mailings.
But it's all-or-nothing. If upstream subscribes, they still get a
load of reports about packaging issues, etc, that should have been
dealt with downstream.
synthesis
---
It is possible for upstream to get all bug reports that aren't handled
downstream, and for downstream to provide a real service for upstream,
at minimal expense.
First, upstream should have to subscribe to receive any reports.
However, as Stefano mentioned, another option would be provided. I called it
Receive only triaged reports.
I pictured the downstream responder assessing whether the problem was
for upstream or downstream, and just clicking a button -- like
Report Upstream,
which would send the report upstream immediately.
Finally, so that no reports slip through, if the report's status isn't
changed, and the report isn't sent upstream, before some prescribed
time-out, the report is automatically sent upstream.
Of course, it is bad that this should happen, and perhaps a discussion
should ensue, but it is MUCH WORSE to let a real bug report just sit
there.
Furthermore, various other possibilities of tracking reporting
statistics would be possible with such an arrangement.
Cheers!
--
On Tue, Sep 13, 2011 at 3:14 PM, Stefano Zacchiroli z...@debian.org wrote:
After GHM [1], I've head a lengthy discussion with Steve White (Cc:-ed,
GNU maintainer [upstream]) about Debian's procedures for forwarding bugs
upstream.
[1] http://lists.debian.org/debian-project/2011/09/msg4.html
The conversion touched the usual suspects:
- Debian is committed to forward bugs upstream
- that should happen in a timely manner but only after triaging
(otherwise many upstream will get upset for non relevant reports)
- due to manpower issue that does not always happen (timely) and some
upstream might get upset about that
- PTS subscriptions mitigate the problem, but only for upstreams willing
to withstand the load of all untriaged Debian bugs (that might be
significant and prone to many false positives for popular software)
A tentative bottom line of the discussion is that:
- we are not always doing our part in forwarding bugs upstream (of
course: we try hard, but we can surely do better) and there will
always be corner cases (e.g. MIA maintainers, orphaned packages, etc.)
- we do offer mechanisms that upstream could use to mitigate the
problem, but they have significant drawbacks
Steve suggested a feature that might improve the status quo:
- enable people to subscribe to bug traffic only if it matches specific
tags (the idea being of forwarding upstream only the traffic for
confirmed bugs)
- add a DELAYED-like mechanism where upstream is notified of a bug only
if the package maintainer fails to deal with the bug in a specific
timeframe, say, 10 days (deal with may be defined in various ways,
e.g.: post to the bug log, closes the bug, details need to be
fleshed out a bit on this point)
Both features will most likely end up being proper feature requests
against the BTS and/or the PTS. They look completely non-intrusive with
respect to what we already offer and they will be opt-in anyhow. The
DELAYED part is not entirely trivial to implement, but Steve is
interested in helping out.
The main reason why I'm posting here is to gather feedback about the
idea, in particular from people willing to try guessing whether their
respective upstreams could benefit from something similar or not.
Many thanks to Steve for the interesting discussion!
Cheers.
--
Stefano Zacchiroli zack@{upsilon.cc,pps.jussieu.fr,debian.org} . o .
Maître de conférences .. http://upsilon.cc/zack .. . . o
Debian Project Leader ... @zack on identi.ca ... o o o
« the first rule of tautology club is the first rule of tautology club »
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive:
http://lists.debian.org/CAEmWKkS6v_q_hNBMoW2dE5MgZAq=Wv5j_t=o+tvhim3sj+o...@mail.gmail.com
Re: forwarding bugs upstream - opt-in, delayed, automated
Hi, status quo - *If upstream is aware of the option*, they can choose to be advised of all bugs or none. This gives upstream some control, and protects downstream from accusations of spamming, since upstream has to subscribe to mailings. But it's all-or-nothing. If upstream subscribes, they still get a load of reports about packaging issues, etc, that should have been dealt with downstream. even if upstream is interested in bug reports (may be even in all of them) - it is not that easy to figure out how to subscribe to the bug mails of a package. We should make it easier for upstreams to subscribe to bts mails. May be also implement a weekly summary of bug mails instead of spamming every single bug mail. Just my 2c :) Cheers, Bernd -- Bernd ZeimetzDebian GNU/Linux Developer http://bzed.dehttp://www.debian.org GPG Fingerprints: ECA1 E3F2 8E11 2432 D485 DD95 EB36 171A 6FF9 435F -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4e7098cf.6000...@bzed.de
Re: forwarding bugs upstream - opt-in, delayed, automated
On Sep 13, 2011, at 04:48 PM, Don Armstrong wrote: The main thing that is blocking me from implementing it currently is a set of perl modules which can handle the hard bit of managing a mailing list correctly so I don't have to write them from scratch. Can you provide a bit more detail on this? I don't know what you need but maybe it's something that Mailman 3 could help with? -Barry signature.asc Description: PGP signature
Re: forwarding bugs upstream - opt-in, delayed, automated
On Wed, Sep 14, 2011 at 02:06:39PM +0200, Bernd Zeimetz wrote:
even if upstream is interested in bug reports (may be even in all of
them) - it is not that easy to figure out how to subscribe to the bug
mails of a package. We should make it easier for upstreams to subscribe
to bts mails. May be also implement a weekly summary of bug mails
instead of spamming every single bug mail.
This is a bit tangential to the rest of the discussion, but exactly the
same has occurred to me. We do have useful Reply or subscribe to this
bug. notices on individual bug pages, but we have nothing of the sort
for pkgreport.cgi pages.
Does anyone care to propose a feature request (possibly with patch) for
the corresponding template with a short mention that the PTS could be
used to subscribe to package bugs? As we already have a line mentioning
the PTS, that could probably be done using very little extra space (for
a lot of benefit, IMHO).
Cheers.
--
Stefano Zacchiroli zack@{upsilon.cc,pps.jussieu.fr,debian.org} . o .
Maître de conférences .. http://upsilon.cc/zack .. . . o
Debian Project Leader... @zack on identi.ca ...o o o
« the first rule of tautology club is the first rule of tautology club »
signature.asc
Description: Digital signature
Re: forwarding bugs upstream - opt-in, delayed, automated
On Tue, 13 Sep 2011 15:14:33 +0200, Stefano Zacchiroli wrote: Steve suggested a feature that might improve the status quo: I like the idea. - enable people to subscribe to bug traffic only if it matches specific tags (the idea being of forwarding upstream only the traffic for confirmed bugs) I'd say: tagged confirmed + upstream (confirmed alone can also be set on a packaging-specific bug) and no forwarded field (if it's already forwarded they know about it already). Cheers, gregor -- .''`. Homepage: http://info.comodo.priv.at/ - PGP/GPG key ID: 0x8649AA06 : :' : Debian GNU/Linux user, admin, developer - http://www.debian.org/ `. `' Member of VIBE!AT SPI, fellow of Free Software Foundation Europe `-NP: Dire Straits: Wild West End signature.asc Description: Digital signature
forwarding bugs upstream - opt-in, delayed, automated
After GHM [1], I've head a lengthy discussion with Steve White (Cc:-ed,
GNU maintainer [upstream]) about Debian's procedures for forwarding bugs
upstream.
[1] http://lists.debian.org/debian-project/2011/09/msg4.html
The conversion touched the usual suspects:
- Debian is committed to forward bugs upstream
- that should happen in a timely manner but only after triaging
(otherwise many upstream will get upset for non relevant reports)
- due to manpower issue that does not always happen (timely) and some
upstream might get upset about that
- PTS subscriptions mitigate the problem, but only for upstreams willing
to withstand the load of all untriaged Debian bugs (that might be
significant and prone to many false positives for popular software)
A tentative bottom line of the discussion is that:
- we are not always doing our part in forwarding bugs upstream (of
course: we try hard, but we can surely do better) and there will
always be corner cases (e.g. MIA maintainers, orphaned packages, etc.)
- we do offer mechanisms that upstream could use to mitigate the
problem, but they have significant drawbacks
Steve suggested a feature that might improve the status quo:
- enable people to subscribe to bug traffic only if it matches specific
tags (the idea being of forwarding upstream only the traffic for
confirmed bugs)
- add a DELAYED-like mechanism where upstream is notified of a bug only
if the package maintainer fails to deal with the bug in a specific
timeframe, say, 10 days (deal with may be defined in various ways,
e.g.: post to the bug log, closes the bug, details need to be
fleshed out a bit on this point)
Both features will most likely end up being proper feature requests
against the BTS and/or the PTS. They look completely non-intrusive with
respect to what we already offer and they will be opt-in anyhow. The
DELAYED part is not entirely trivial to implement, but Steve is
interested in helping out.
The main reason why I'm posting here is to gather feedback about the
idea, in particular from people willing to try guessing whether their
respective upstreams could benefit from something similar or not.
Many thanks to Steve for the interesting discussion!
Cheers.
--
Stefano Zacchiroli zack@{upsilon.cc,pps.jussieu.fr,debian.org} . o .
Maître de conférences .. http://upsilon.cc/zack .. . . o
Debian Project Leader... @zack on identi.ca ...o o o
« the first rule of tautology club is the first rule of tautology club »
signature.asc
Description: Digital signature
Re: forwarding bugs upstream - opt-in, delayed, automated
Stefano Zacchiroli z...@debian.org writes: Steve suggested a feature that might improve the status quo: - enable people to subscribe to bug traffic only if it matches specific tags (the idea being of forwarding upstream only the traffic for confirmed bugs) I'd love this, even with having only my BTS-junkie hat on. This would allow me to subscribe to, say, security or $arch-related bugs for a select number of packages I depend on for $work, or packages I'm more familiar with. Without the disadvantage of also receiving all kinds of reports I can't do a thing about. This would certainly be a far more pleasant experience than subscribing to -bugs-dist and trying to filter based on how many messages a particular bug received, and how often certain words appeared in the messages.. While none of my current upstreams would be interested in this feature, I think, I do know that there are upstreams, who would be very interested. - add a DELAYED-like mechanism where upstream is notified of a bug only if the package maintainer fails to deal with the bug in a specific timeframe, say, 10 days (deal with may be defined in various ways, e.g.: post to the bug log, closes the bug, details need to be fleshed out a bit on this point) For similar reasons that I liked the other suggested feature, I see great value in this one too: mortal users can subscribe to packages they depend on, or know better than others, and easily get notified when the package needs manpower. -- |8] -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87r53kjx19@luthien.mhp
Re: forwarding bugs upstream - opt-in, delayed, automated
On 09/13/2011 03:14 PM, Stefano Zacchiroli wrote: - enable people to subscribe to bug traffic only if it matches specific tags (the idea being of forwarding upstream only the traffic for confirmed bugs) - add a DELAYED-like mechanism where upstream is notified of a bug only if the package maintainer fails to deal with the bug in a specific timeframe, say, 10 days (deal with may be defined in various ways, e.g.: post to the bug log, closes the bug, details need to be fleshed out a bit on this point) Both features will most likely end up being proper feature requests against the BTS and/or the PTS. They look completely non-intrusive with respect to what we already offer and they will be opt-in anyhow. The DELAYED part is not entirely trivial to implement, but Steve is interested in helping out. The DELAYED one should be easy to implement as the BTS SOAP interface [1] already has the notion of a log_modified attribute which holds the DateTime of last update of the bug (and a date attribute which is the DateTime of creation of the bug). The tags attribute in the BTS SOAP interface obviously contains the bug tags, but I'm unsure if that would be enough. It could be a start for confirmed, security and the like though. Should it be implemented in the PTS? How would DELAYED be defined, a fixed amount of days old? How would the selection of the tags be done? Cheers Luk [1] http://wiki.debian.org/DebbugsSoapInterface -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4e6f90fb.7010...@debian.org
Re: forwarding bugs upstream - opt-in, delayed, automated
Quoting Stefano Zacchiroli (z...@debian.org): After GHM [1], I've head a lengthy discussion with Steve White (Cc:-ed, GNU maintainer [upstream]) about Debian's procedures for forwarding bugs upstream. [1] http://lists.debian.org/debian-project/2011/09/msg4.html The conversion touched the usual suspects: This is indeed the consequence of a discussion we (font packages maintainers) had with Steve about the ttf-freefont package (which Steve is upstream for). Great to see that it lead to something interesting Steve suggested a feature that might improve the status quo: - enable people to subscribe to bug traffic only if it matches specific tags (the idea being of forwarding upstream only the traffic for confirmed bugs) - add a DELAYED-like mechanism where upstream is notified of a bug only if the package maintainer fails to deal with the bug in a specific timeframe, say, 10 days (deal with may be defined in various ways, e.g.: post to the bug log, closes the bug, details need to be fleshed out a bit on this point) I think these are really interesting features and I would have loved having them handy when we had this mail discussion with Steve about the status of some ttf-freefont bugs..:-) Thanks for having the discussion face to face (which is always much easier than asynchronously by mail) and ending up with both these features. I know at least of one of my upstreams who would appreciate them, namely Steve himself..:-) signature.asc Description: Digital signature
Re: forwarding bugs upstream - opt-in, delayed, automated
On Tue, 13 Sep 2011, Gergely Nagy wrote: Stefano Zacchiroli z...@debian.org writes: Steve suggested a feature that might improve the status quo: - enable people to subscribe to bug traffic only if it matches specific tags (the idea being of forwarding upstream only the traffic for confirmed bugs) I'd love this, even with having only my BTS-junkie hat on. This would allow me to subscribe to, say, security or $arch-related bugs for a select number of packages I depend on for $work, or packages I'm more familiar with. Without the disadvantage of also receiving all kinds of reports I can't do a thing about. A fully formed system which does this would be excellent. The main thing that is blocking me from implementing it currently is a set of perl modules which can handle the hard bit of managing a mailing list correctly so I don't have to write them from scratch. Given one that doesn't suck, I'd be able to implement this soonish. Don Armstrong -- You think to yourself, hey, it's a test tube, for God's sake. Pretty soon, though, the rush from a test tube isn't enough. You want to experiment more and more. Then before you know it, you're laying in the corner of a lab somewhere with a Soxhlet apparatus in one hand, a three neck flask in the other, strung out and begging for grant money. -- Tim Mitchell, 1994 Ig Nobel Chemistry Prize Speech http://www.donarmstrong.com http://rzlab.ucr.edu -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110913234848.gm16...@rzlab.ucr.edu
