You can not select more than 25 topics
Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
65 lines
2.5 KiB
65 lines
2.5 KiB
reportbug now has public CVS read access at:
|
|
|
|
http://cvs.alioth.debian.org/cgi-bin/cvsweb.cgi/reportbug/
|
|
|
|
--
|
|
|
|
Silly TODO list for 3.0 (possibly sarge, depending on RM's mood):
|
|
|
|
1. Document reportbug.conf properly in a man page.
|
|
|
|
Silly TODO list for 4.0 (sarge+1):
|
|
|
|
1. Proper GNOME interface. My current thinking is to hack the
|
|
bug-buddy Glade file to pieces, or do something similar in straight
|
|
PyGTK, and give up on the whole "UI abstraction" nonsense for now.
|
|
|
|
(To give you an idea of the limitations of the GNOME Druid widget,
|
|
bug-buddy doesn't even use a Druid... instead, it's a giant
|
|
notebook hack that emulates a Druid in appearance.)
|
|
|
|
2. Convert the modules to a proper package and stick it in the Python
|
|
search path (per #157079). Reform the names. Rename
|
|
"reportbug.py" to something sensible. This probably has to be done
|
|
before #1 can happen.
|
|
|
|
(Not sure of a good approach here. Maybe we should have a class
|
|
that carries around all the information for a bug report, and be
|
|
able to do stuff like "report.get_debconf_settings()" and the like
|
|
when we go talking to external tools like dpkg, debconf-show,
|
|
debsums, etc.)
|
|
|
|
3. BTS management interface for developers. You should be able to
|
|
view the list of bug reports for a package, construct a list of
|
|
actions, and produce one giant email to control@bugs.debian.org to
|
|
do that. Forwarding and merging, which both can be major PITAs,
|
|
will be helpful. (See #157283)
|
|
|
|
("devscripts" has the bts command. This is hence a very low priority.)
|
|
|
|
4. i18n/l10n.
|
|
|
|
(i18n/l10n with reportbug may not make much sense, since the
|
|
reports have to be in English for most maintainers to understand
|
|
them... unless we figure out some way to get bug reports translated
|
|
for maintainers.)
|
|
|
|
5. Convert BTS code to use the mbox-format reports if available, as
|
|
they should be easier to parse.
|
|
|
|
6. Alternatively, cajole the BTS maintainers into producing an XML
|
|
serialization of the BTS data. (See #184983)
|
|
|
|
7. Allow followups from the command line using a specific bug number,
|
|
rather than requiring people to go through the browser. Coupled
|
|
with --query-only, this should allow me to drop querybts
|
|
completely. (See #223335)
|
|
|
|
8. Optionally display changelogs for new upstream versions.
|
|
(See: #241552) Perhaps it should cooperate with apt-listchanges
|
|
somehow to do this?
|
|
|
|
9. Improve MUA code to allow arbitrary arguments to MUAs; see #271084.
|
|
|
|
10. Multiple BTS support (again), which probably means "Bugzilla
|
|
support" for Ubuntu, etc.
|
|
|