launchpad-dev team mailing list archive
Mailing list archive
Re: On forwarding bugs upstream
Sorry for breaking in but I personnaly would love to be more involved in
Debian's BTS, if there was an easy way to report back (even an official
Ubuntu tutorial for this) I would do so.
I usually need forwarding bugs to the source projects (such as GNOME) since
I maintaing both translations and most of the GNOME Hebrew or RTL related
bugs pass through me anyway.
Just a personal point of view, thank you all for hearing me out.
Yaron Shahrabani - Ubuntu Hebrew maintainer.
On Thu, Mar 17, 2011 at 6:01 PM, Jonathan Lange <jml@xxxxxxxxxxxxx> wrote:
> 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
> > 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
> > 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
> 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.
> is something that makes Debian the opposite of enjoyable, and I think I
> those tasks sit longer than I should, and work on things instead where I
> actually contribute (such as fixing Debian bugs).
> Others point out that the Debian maintainer acts as an expert filter &
> 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
> should only be enabled with respect to an upstream BTS after discussion
> 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
> 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
> 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
> 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:
> Mailing list: https://launchpad.net/~launchpad-dev
> Post to : launchpad-dev@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~launchpad-dev
> More help : https://help.launchpad.net/ListHelp