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
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
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
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
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
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
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?
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
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
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
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
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
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
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
14 matches
Mail list logo
