Package: reportbug
Version: 3.39
Severity: normal
Bug#1: BTS server inappropriately responds to user messages
The debian bug tracking system is sending me parse errors when I reply
to responses from package maintainers. Naturally, I reply to all recipients
as this
is necessary to insure that a copy gets to the maintainer and the BTS itself.
[EMAIL PROTECTED] being included in the maintainers responses is probably
implicated.
BTS probably should not parse commands unless they are preceeded by some sort of
escape character.
Bug#2: Where to report debian BTS bugs?
This is a report on the BTS itself which either doesn't have a psuedo package
name
of its own or the existence of said name is not properly documented on the web
site where users can find it. Bug #2
Bug #3: Disposition "overburdened"
Package maintainers frequently close bugs inappropriately
because they are overburdened. Bugs should never be closed for this
reason. They should be tagged with a suitable disposition such as
"overburdened"
so they will eventually be fixed when an additional maintainer comes on board or
the existing maintainers have more time. So, I propose that this be added as
a
standard category. It is possible that the "help" disposition is intended for
this; if so,
it needs to be better documented that this is the case. Fix involves adding
a new disposition and/or improving documentation (including website and
debian policy manual)for maintainers.
Bug #4: Bug Tacking System Interoperability.
the debian bug tracking system does not appear to have facilities
for reassigning bugs to foreign bug tracking systems (i.e. to the upstream
package).
This is not a small undertaking, but it needs to be done. I am not a debian
package
maintainer but users are affected by this and it contributes to package
maintainers
being overburdened. This should be done in an automated
way that preserves as much information as possible and links the systems
together
as much as possible so package maintainers are notified when a bug is
fixed upstream. At the very least, hyperlinks should automatically be added
from each system to the other. You should be able to assign a package
to fix-upstream and when it is fixed upstream it pehaps gets automatically
retagged "fixed-upstream". Maintainers should have a menu for reassigning
bugs that includes each dependency package and each upstream package.
iceweasel would be a prime example. mozilla doesn't accept bugs on the
debian version.
- user submits bug
- debian packager verifies that it is a mozilla bug and not a debian induced
bug
this would include testing on a stock firefox version.
- package maintainer reassings bug to mozilla.
- mozilla finds the problem is in a library and reassigns it upstream
(for completeness, depends on their BTS, not debian's).
Clearly debian users are not being properly served under the present system.
Any software developed for this should have a permissive license so it can
be linked to different bug tracking systems. I am thinking that initially,
the debian BTS could submit the bug on other systems web forms but longer
term a common API should exist. So, a basic library for submitting to
web forms is needed, with support for mapping from one field to another and
mapping values. Email, with appropriately tagged info, could be used where
foreign system takes bug reports by email. Where each system has email
notification
of updates, the system could subscribe each to the other's list but protection
is needed against mail loops. Server command should be prefixed by a system
id:
$$$server bugs.debian.org disposition=closed
$$$server bugzilla.mozilla.org disposition=closed
bugzilla seems to support XML-RPC and seems close to being able to
at least talk between bugzilla implementations:
http://wiki.mozilla.org/Bugzilla:Meetings:2007-08-07 says:
"But with the coming implementation of Bug->update and additional
XML-RPC methods, it would become possible for one Bugzilla installation
to interact with other installations. This seems to be important enough
to worth calling the next release Bugzilla 4.0. Said otherwise,
Bugzilla 4.x installations would be able to talk to each other."
http://wiki.mozilla.org/Testopia:Documentation:XMLRPC
Bug #5: Filing multiple bugs in one report.
While the debian system supports cloning, it would be better if bug reports
were submitted broken down as:
- prologue (common to all)
- bug #1
- bug #2
- bug #3
- epilogue (common to all)
- automatically collected information
This is easier with a web form. Reportbug spawns an editor; the text could
be prepopulated with tags to divide into sections. Such a system would
automatically create multiple bug reports, with hyperlinks cross referencing
them.
reportbug-ng could do a better job.
bug #6: BTS doesn't identify and link to the software used
http://www.chiark.greenend.org.uk/~ian/debbugs/
Ironically, it doesn't include info on reporting bugs on the software.
Bugs numbered for ease of cloning.
-- Package-specific info:
** Environment settings:
EDITOR="scite"
VISUAL="scite"
INTERFACE="text"
** /home/whitis/.reportbugrc:
reportbug_version "3.8"
mode standard
ui text
realname "Mark Whitis"
email "[EMAIL PROTECTED]"
-- System Information:
Debian Release: lenny/sid
APT prefers unstable
APT policy: (990, 'unstable'), (500, 'testing'), (500, 'stable')
Architecture: i386 (i686)
Kernel: Linux 2.6.22-2-686 (SMP w/1 CPU core)
Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1)
Shell: /bin/sh linked to /bin/bash
Versions of packages reportbug depends on:
ii apt 0.7.9 Advanced front-end for dpkg
ii python 2.4.4-6 An interactive high-level object-o
ii python-central 0.5.15 register and build utility for Pyt
reportbug recommends no packages.
-- no debconf information
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
