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.

53 lines
2.0 KiB

reportbug now has public CVS read access at:
Silly TODO list for 3.0 (possibly etch, depending on RM's mood):
1. Document reportbug.conf properly in a man page.
Silly TODO list for 4.0 (etch+1), in no particular order:
1. Convert the modules to a proper package and stick it in the Python
search path (per #157079). Reform the names. Rename
"" to something sensible.
(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.)
2. 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 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.)
3. 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.)
4. Cajole the BTS maintainers into producing an XML serialization of
the BTS data. (See #184983)
5. 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)
6. Optionally display changelogs for new upstream versions.
(See: #241552) Better yet, show bugs fixed between current version
installed first in the BTS browser.
7. Improve MUA code to allow arbitrary arguments to MUAs; see #271084.
8. Multiple BTS support (again), which probably means "Bugzilla
support" for Ubuntu, etc.