1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
|
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.
|
