[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Firefox bugs mass-closed.



On Tue, 2 Oct 2007 08:25:21 -0500
John Goerzen <jgoerzen@complete.org> wrote:

> As a maintainer and a user, I have often wondered lately if the practice of 
> tracking numerous upstream bugs in the Debian BTS is something that should 
> be ended.  We nominally do this out of convenience to our users.  However, I 
> have found response time from Debian maintainers for upstream bugs, on 
> average, to be extremely bad, and that most never get forwarded to the 
> upstream BTS. 

When that is actually all that needs to be done, it is disappointing.
There are automated systems that track forwarded bugs but the sheer
number and variety of upstream bug tracking methods may be a problem.
Are there upstream systems that cannot be tracked by our automated
scripts? How many? As long as the "Forwarded to:" location is publicly
accessible and contains sane data on the status of the bug, it should
be possible to track most upstream systems.

For my own upstream packages, I actually prefer to use the Debian BTS
because the SourceForge Trackers are a PITA. (YMMV). So with my
upstream packages, there *are* no upstream bugs!
:-)

> As a maintainer, I must admit to not always being prompt with 
> upstream bugs myself.  When I have an active upstream, it is annoying to act 
> as a human proxy when the issue could be best handled through them directly 
> anyway.

The problem, for me, is when each upstream has a radically different
bug tracking system - particularly when each one requires
yet-another-username-and-password, most do not accept direct email and
many are incredibly long-winded. Why should it take FIVE pages (after
login) just to get to the text entry box? It's easier once you've filed
a few bugs but that just means that it is a job for the maintainer
rather than each user.

> I have received a number of pings lately similar to the one that sparked this 
> thread.  Some for bugs many years old that never received any attention 
> whatsoever.  All were upstream bugs.

Forwarded?

If the bug has been forwarded, it is up to the person writing the ping
to skip those bugs (or maybe follow the link to the upstream).
 
> As a rule, I try to never report upstream bugs to the Debian BTS anymore 
> because it is a blackhole in so many cases.

Not reporting to the BTS can just mean that someone else (with less
knowledge of the package and possibly less useful input) files a BTS
bug anyway. At least having the bug in the BTS can reduce duplicates /
provide a base bug into which to merge duplicates.

> Perhaps we should be providing tools to let users find the appropriate 
> upstream BTS for upstream bugs, rather than burdening our maintainers with 
> being a human proxy?  I suspect we will provide better response for the 
> users and a better BTS for maintainers.

Users don't want to create whole new username-and-password pairs
either. Debian should not expect Debian users to know how to use
upstream bug systems. If the upstream system can accept reports from
reportbug, fine (although I suspect most will not).
 
> Of course, the question is how to determine what's an upstream bug.  Perhaps 
> we could still receive reports in our Debian BTS, but provide some automated 
> tools to send them on to popular types of upstream BTSs, and then close the 
> Debian report with a pointer to the upstream location?

I think it would be better to identify which upstreams use systems that
cannot be tracked once forwarded and prompting maintainers to use the
forwarded tag that already exists.

-- 


Neil Williams
=============
http://www.data-freedom.org/
http://www.nosoftwarepatents.com/
http://www.linux.codehelp.co.uk/

Attachment: pgpRB7HW1UoUu.pgp
Description: PGP signature


Reply to: