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 <zack@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/msg00004.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 »
>
Reply to: