ubuntu-bugcontrol team mailing list archive
Mailing list archive
Re: [Launchpad-dev] On forwarding bugs upstream
On Tue, Mar 15, 2011 at 1:42 PM, Matt Zimmerman <mdz@xxxxxxxxxx> wrote:
> Given there has been a lot of discussion around forwarding bugs upstream via
> Launchpad, I thought folks here might be interested in this debian-devel
> It's long and wandering, but there is a lot of valuable first-hand
> perspective in there from folks who have done a lot of bug forwarding and
> package maintenance.
There is. Thanks for forwarding it on.
> I wish I could spend the time to summarize it, but thought it couldn't hurt
> to pass it on.
Many of the problems here and much of the thinking are familiar to us:
* There are far, far too many bug reports to ever finish
* Forwarding bugs upstream is complex both technically and socially,
no blanket approach will ever work
* In particular, you need to think of what the communications will
look like after forwarding
Some things that weren't related to forwarding that I found interesting:
* Debian folk really like their BTS
* Account management was a recurring theme
As Matt says, there's a lot there worth reading. If you're interested
in the problem, take a look.
Here are my highlights:
maintainers should forward bugs upstream instead of requiring (or strongly
encouraging) users to do so
If a bug is not readily reproducible or isolatable, it may be necessary
to pass it over to an upstream maintainer who will know what further
questions to ask. But they need to send those questions to the user,
not to the Debian maintainer. In the kernel team, we often ask users to
report bugs upstream for that reason.
Ditto on the X side. Having a low-power proxy between developers and
users is quite a bad idea (induces delays and higher load).
Thoughtful rejection of "we should forward bugs upstream on behalf of
It is a huge and frustrating waste of my time. It is also frustrating for
upstream, who would rather just talk with the user directly and involve me
if they think there's a Debian-specific question. I don't understand why
some users want it to go this way, but many clearly do despite the fact that
they get worse service.
I'm going to be brutally honest and admit here that being a copy and paste
monkey between emails and web forms is something I really dislike doing. It
is something that makes Debian the opposite of enjoyable, and I think I let
those tasks sit longer than I should, and work on things instead where I can
actually contribute (such as fixing Debian bugs).
Others point out that the Debian maintainer acts as an expert filter & refiner
of information for the upstream, not just a "copy and paste monkey".
I personally would love to see patches to the BTS to enable forwarding
these kinds of bug reports to upstreams more easily and integrate
everything tightly with the BTS. Unfortunately, I am perpetually short
of time to implement them myself, as excellent as I am certain they
That would be a very nice feature for our BTS to have. BUT any such feature
should only be enabled with respect to an upstream BTS after discussion with
and approval from the relevant upstream.
As we can see from this and previous discussions: how easy to make it to
file bugs, who can file them, how they get to be filed, and so on, are
things that people care about and have strong opinions about. Different
projects have different cultural and technical expectations.
Anecdote: while I was employed by Canonical I had to dissuade some of my
colleagues from implementing and deploying, without consent from Debian, a
feature in Launchpad that would automatically file corresponding bug reports
in the Debian BTS. I expressed the view that doing so would be considered
abuse by the Debian BTS admins and would probably result in some emergency
ad-hoc wholesale blocking of Launchpad's access to Debian infrastructure.
Not to mention an absolutely enormous flamewar.
To all of us that would obviously have been a really bad idea. Let us be
careful not to do to our upstreams what we don't want our downstreams to do
to us. (Ian Jackson)
The bts-link system takes care of polling for upstream bug status updates for
several common bug trackers
Upstream tend to request users to install latest and greatest versions,
often for source or using other unsafe methods. Not only for package in
question but also for explicit and implicit dependences. Non-technical
follow these broken advices and break their systems. And then complain
that Debian is problematic for them.
I think that forwarding user upstream is acceptable only for deeply
technical users. But but not as a default policy.
Not all upstreams are like that, but I think that brings to the front an
important point: there are vast differences in users, in upstreams, and in
Reflections on the danger of non-maintainer triagers:
Distributed bug tracking: