On Tue, 2 Oct 2007 08:25:21 -0500 John Goerzen <[EMAIL PROTECTED]> 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/
pgpiAQdkE16Jy.pgp
Description: PGP signature
