FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Ubuntu > Launchpad User

 
 
LinkBack Thread Tools
 
Old 12-03-2007, 03:16 PM
Mario Limonciello
 
Default Forwarding bugs upstream

Hi,

I had a bit of a feature request that I was surprised to not see
available in Launchpad. Currently you can register an external tracker
for a project that is regularly checked for bug updates. This appears
to be a one way sync.

Why can't launchpad file bugs with these external trackers too? I can
see it being very useful if it could be a two-way sync that on bugs that
are listed as affecting an upstream project, all of the comments get
posted to both trackers. The way I see it, there should be a checkbox
for people in say ~ubuntu-qa when you say that the bug affects an
upstream project, to "sync" the two bugs both ways.

Without this, it is appearing for several projects that apport reported
bugs are just turning up into a black hole. Look at vlc [1] or mplayer
[2]. MOTU can't keep up with all of the bugs filed, let alone solve a
lot of these locally due to the understanding of the code required to
solve them. They would be much more relevant to the upstream
developers, but most projects don't like to have to be using two bug
trackers (in LP and their own) to manage all the bugs, and won't be
willing to change. To the same effect, there aren't enough resources
for MOTU to forward every single one of these bugs by hand to the
upstream project.

[1]
https://bugs.edge.launchpad.net/ubuntu/+source/vlc/?field.searchtext=apport&orderby=-importance&search=Search&field.status%3Alist=NEW&f ield.status%3Alist=INCOMPLETE_WITH_RESPONSE&field. status%3Alist=CONFIRMED&field.status%3Alist=TRIAGE D&field.status%3Alist=INPROGRESS&field.status%3Ali st=FIXCOMMITTED&field.assignee=&field.bug_reporter =&field.omit_dupes=on&field.has_patch=&field.has_n o_package=
[2]
https://bugs.edge.launchpad.net/ubuntu/+source/mplayer/?field.searchtext=apport&orderby=-importance&search=Search&field.status%3Alist=NEW&f ield.status%3Alist=INCOMPLETE_WITH_RESPONSE&field. status%3Alist=CONFIRMED&field.status%3Alist=TRIAGE D&field.status%3Alist=INPROGRESS&field.status%3Ali st=FIXCOMMITTED&field.assignee=&field.bug_reporter =&field.omit_dupes=on&field.has_patch=&field.has_n o_package=

Regards,

--
Mario Limonciello
superm1@ubuntu.com


--
launchpad-users mailing list
launchpad-users@lists.canonical.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/launchpad-users
 
Old 12-03-2007, 03:47 PM
Christian Robottom Reis
 
Default Forwarding bugs upstream

On Mon, Dec 03, 2007 at 10:16:44AM -0600, Mario Limonciello wrote:
> Why can't launchpad file bugs with these external trackers too? I can
> see it being very useful if it could be a two-way sync that on bugs that
> are listed as affecting an upstream project, all of the comments get
> posted to both trackers. The way I see it, there should be a checkbox
> for people in say ~ubuntu-qa when you say that the bug affects an
> upstream project, to "sync" the two bugs both ways.

We want to do this, and it's on our six-month roadmap. This isn't a
trivial endeavour: it requires finding ways to file the bugs upstream,
which is technically easy for some (i.e. debbugs) and more difficult for
others (i.e. sourceforge). There are also concerns about communication
between the bugtrackers -- if we file a bug upstream we don't want the
reporter to be a black hole. We're taking lots of different approaches,
and you'll see changes in this area in the coming months. Ask Bjorn for
more details!
--
Christian Robottom Reis | http://async.com.br/~kiko/ | [+55 16] 3376 0125

--
launchpad-users mailing list
launchpad-users@lists.canonical.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/launchpad-users
 
Old 01-11-2011, 10:54 PM
"brian m. carlson"
 
Default Forwarding bugs upstream

I've noticed a trend lately that I am often asked to forward the bugs I
report to the Debian BTS upstream, either by the maintainers or
automatically by a bug script. I believe, and I continue to believe,
that maintainers should forward bugs upstream instead of requiring (or
strongly encouraging) users to do so.

I understand that maintainers' time is limited and that forwarding bugs
is not an enjoyable task. But I also understand that having a BTS
account for the upstream BTS of each of the 2405 packages I have
installed on my laptop (not to mention my other machines) is simply not
practical. I also don't have the benefit of the rapport that a
maintainer has with upstream and knowledge of upstream practices.

I try very hard to make my bug reports simple, clear, and well-defined
(often with testcases) to make it easier for them to be forwarded and
fixed, and if they're not, I'm happy to clarify or test so that they can
be. And I try to submit patches as my time and abilities permit. If it
happens that I need to be added to the CC list of the upstream bug
report to assist in fixing it, I'm usually fine with that if asked.

To clarify, this is not in reference to any particular package or
maintainer; it's just something I've noticed and wanted to bring up.

--
brian m. carlson / brian with sandals: Houston, Texas, US
+1 832 623 2791 | http://www.crustytoothpaste.net/~bmc | My opinion only
OpenPGP: RSA v4 4096b: 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187
 
Old 01-11-2011, 11:45 PM
Ben Hutchings
 
Default Forwarding bugs upstream

On Tue, 2011-01-11 at 23:54 +0000, brian m. carlson wrote:
> I've noticed a trend lately that I am often asked to forward the bugs I
> report to the Debian BTS upstream, either by the maintainers or
> automatically by a bug script. I believe, and I continue to believe,
> that 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.

> I understand that maintainers' time is limited and that forwarding bugs
> is not an enjoyable task. But I also understand that having a BTS
> account for the upstream BTS of each of the 2405 packages I have
> installed on my laptop (not to mention my other machines) is simply not
> practical.

Surely you don't find bugs in all of those packages?

> I also don't have the benefit of the rapport that a
> maintainer has with upstream and knowledge of upstream practices.
>
> I try very hard to make my bug reports simple, clear, and well-defined
> (often with testcases) to make it easier for them to be forwarded and
> fixed,
[...]

In that sort of case, yes, it is hard to see a justification for a
maintainer requiring you to report again upstream.

Ben.

--
Ben Hutchings
Once a job is fouled up, anything done to improve it makes it worse.
 
Old 01-11-2011, 11:59 PM
Cyril Brulebois
 
Default Forwarding bugs upstream

Ben Hutchings <ben@decadent.org.uk> (12/01/2011):
> 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).

KiBi.
 
Old 01-12-2011, 12:15 AM
Ben Finney
 
Default Forwarding bugs upstream

"brian m. carlson" <sandals@crustytoothpaste.net> writes:

> I've noticed a trend lately that I am often asked to forward the bugs
> I report to the Debian BTS upstream, either by the maintainers or
> automatically by a bug script. I believe, and I continue to believe,
> that maintainers should forward bugs upstream instead of requiring (or
> strongly encouraging) users to do so.

+1

> I understand that maintainers' time is limited and that forwarding
> bugs is not an enjoyable task. But I also understand that having a BTS
> account for the upstream BTS of each of the 2405 packages I have
> installed on my laptop (not to mention my other machines) is simply
> not practical. I also don't have the benefit of the rapport that a
> maintainer has with upstream and knowledge of upstream practices.

Yes, I agree with that position. It is even more reasonable when one
considers that the person who has chosen to be a maintainer for Debian
package ‘foo’ has some amount of obligation to have an account with the
upstream BTS for ‘foo’, whereas an arbitrary user of ‘foo’ does not.

> I try very hard to make my bug reports simple, clear, and well-defined
> (often with testcases) to make it easier for them to be forwarded and
> fixed, and if they're not, I'm happy to clarify or test so that they
> can be. And I try to submit patches as my time and abilities permit.
> If it happens that I need to be added to the CC list of the upstream
> bug report to assist in fixing it, I'm usually fine with that if
> asked.

Yes, this is all a fair expectation of the user by the maintainer, in
exchange for being the contact point for the package in Debian.

--
“To stay young requires unceasing cultivation of the ability to |
` unlearn old falsehoods.” —Robert Anson Heinlein |
_o__) |
Ben Finney
 
Old 01-12-2011, 12:29 AM
Drake Wilson
 
Default Forwarding bugs upstream

Quoth Cyril Brulebois <kibi@debian.org>, on 2011-01-12 01:59:03 +0100:
> > 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).

I tend to think what would be ideal in such cases is for the package
maintainer to go through the overhead motions of forwarding that
require a heavy context switch (i.e., setting the ball rolling) and
then subscribe the user to the relevant bug by email or some other
similar communication mechanism.

Which upstream bug trackers, if any, would make the above not work?
Here I'm ignoring things like maintainer time to do the forwarding,
assuming that that can be analyzed separately. Mainly I'm wondering
about cases where the user essentially _can't_ communicate about the
bug directly without going through rigamarole to "create an account"
first or thereabouts; is this common? If so, and assuming it's much
more expensive for the user to switch into "bug reporting" context, I
find it likely that many users would give up at that point rather than
having to report the bug a second time after having already expended
the context switch effort to report it once.

---> Drake Wilson


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20110112012933.GA3334@drache.begriffli.ch">http://lists.debian.org/20110112012933.GA3334@drache.begriffli.ch
 
Old 01-12-2011, 01:17 AM
Ben Hutchings
 
Default Forwarding bugs upstream

On Tue, 2011-01-11 at 18:29 -0700, Drake Wilson wrote:
> Quoth Cyril Brulebois <kibi@debian.org>, on 2011-01-12 01:59:03 +0100:
> > > 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).
>
> I tend to think what would be ideal in such cases is for the package
> maintainer to go through the overhead motions of forwarding that
> require a heavy context switch (i.e., setting the ball rolling) and
> then subscribe the user to the relevant bug by email or some other
> similar communication mechanism.
>
> Which upstream bug trackers, if any, would make the above not work?
[...]

Bugzilla requires that each subscribed email address has an account.

Ben.

--
Ben Hutchings
Once a job is fouled up, anything done to improve it makes it worse.
 
Old 01-12-2011, 01:55 AM
Paul Wise
 
Default Forwarding bugs upstream

On Wed, Jan 12, 2011 at 9:29 AM, Drake Wilson <drake@begriffli.ch> wrote:

> Which upstream bug trackers, if any, would make the above not work?

Sourceforge and probably Gforge/FusionForge trackers.

The only tracker I'm aware of which would work is Trac, some instances
of which allow anyone to put in anyone else's email address as the
author of the bug.

--
bye,
pabs

http://wiki.debian.org/PaulWise


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: AANLkTinLHyLwOAGoer0ZNgLsLd5xb5qEUmH3VMDetbdE@mail .gmail.com">http://lists.debian.org/AANLkTinLHyLwOAGoer0ZNgLsLd5xb5qEUmH3VMDetbdE@mail .gmail.com
 
Old 01-12-2011, 02:15 AM
John Goerzen
 
Default Forwarding bugs upstream

On 01/11/2011 05:54 PM, brian m. carlson wrote:

I've noticed a trend lately that I am often asked to forward the bugs I
report to the Debian BTS upstream, either by the maintainers or
automatically by a bug script. I believe, and I continue to believe,
that maintainers should forward bugs upstream instead of requiring (or
strongly encouraging) users to do so.


Hi Brian,

I'm going to have a slightly different viewpoint on this.

I think it is perfectly fine for a user to submit a bug report to the
Debian BTS first. They may not always be equipped to know what is a
Debian and what is an upstream bug. And I also think it ought to be
perfectly valid for the Debian developer to close the bug saying it's an
upstream issue, together with a pointer to the upstream BTS and promise
to get involved should there be any question about the Debian packaging,
environment, etc.


Now, here's how it proceeds if I have to forward a bug upstream for
Bacula, which uses Mantis. Creating a Mantis account takes 30 seconds,
but Mantis won't email reports to people without accounts, and the only
way to add stuff to it is on the web.


So, here's how it goes:

1) User submits bug report to Debian.

2) I decide if it is clearly an upstream issue.

3) I go to Mantis and fill out the fields by copying data from the
user's bug report.


4) I mark the bug forwarded and email the user that it's happened.

5) Upstream inevitably has questions or other things for user to try.

6) I forward that email to Debian BTS and user. Maybe I download an
attachment from the Mantis report and attach it to the email.


7) User replies, possibly while I'm sleeping. I log in to Mantis and
copy and paste the answer. I also save off attachments from the email
and then go and attach them to the Mantis report.


8) This continues.

I'm adding zero value here. Zero. 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).


I have a sense that I'm not alone. I've noticed that there are certain
major packages for which upstream bugs tend to get ignored for a year,
then get a big sweep asking if they're still issues, then get ignored
for a year again. I won't mention names here, but I don't think it's
necessarily entirely blame to be laid at maintainers' feet. I just go
and submit upstream bugs upstream on those and go on my merry way.


Maintainers in Debian do undertake certain responsibilities. But I
think that being copy and paste monkeys shouldn't be one of them. If I
were getting paid to work a helpdesk, sure. But really, I think it is
nonsensical for an end user to expect me to do this because the user
doesn't want to spend 30 seconds creating an account on an upstream BTS.
That's not what Free Software is all about. And it has Debian
maintainers wasting time.


I think that promising that Debian maintainers will always shepherd bugs
upstream is promising something we don't actually deliver on very well,
and probably never have. Perhaps we should stop promising it.


This is not to criticize Brian here; he has been perfectly courteous and
up-front in his presentation.


-- John


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 4D2D1CDD.2010608@complete.org">http://lists.debian.org/4D2D1CDD.2010608@complete.org
 

Thread Tools




All times are GMT. The time now is 07:13 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org