launchpad-dev team mailing list archive

[Jonathan Lange <jml@xxxxxxxxxxxxx>]

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
> thread:
>
> http://lists.debian.org/debian-devel/2011/01/msg00309.html
>
> 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
users": <http://lists.debian.org/debian-devel/2011/01/msg00318.html>
(extract below):

  """
  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
would be.
"""

  """
  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)
  """ <http://lists.debian.org/debian-devel/2011/01/msg00395.html>


"""
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
  maintainers.
  """

Reflections on the danger of non-maintainer triagers:
<http://lists.debian.org/debian-devel/2011/01/msg00393.html>

Distributed bug tracking:
<http://lists.debian.org/debian-devel/2011/01/msg00328.html>

jml