File: TODO

package info (click to toggle)
reportbug 13.2.0
  • links: PTS, VCS
  • area: main
  • in suites: forky, sid, trixie
  • size: 1,248 kB
  • sloc: python: 9,838; sh: 70; makefile: 41; lisp: 31
file content (54 lines) | stat: -rw-r--r-- 2,155 bytes parent folder | download
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
TODO list for reportbug 4.0 (squeeze):

0. revisit README.{developers,source} for source code layout section

0.1. fix the way reportbug/querybts obtain a UI: the ideal would be to
     use getUI from reportbug.ui, since the module already has all the
     UIs loaded (to know the ones available).
     bin/reportbug - line 833
     bin/querybts  - line 174

0.3. reportbug/ui/text_ui.py
       + disabled utils.NEWBIELINE check to avoid circular import between text
         and utils ******** WE NEED TO FIND A SOLUTION TO THIS **********

0.4. check for utf-8/weird locales errors

0.5. remove the tmp file only after the report is actually sent (or at least it
     should be configurable?)

0.6. bin/reportbug: refactor the package name check/get/verify or so (now it's
     sparse all around the file

0.7. what's the difference between 'X-Mailer' (as used by reportbug) and
     'User-Agent' (as used by bts)? what's preferred to identify the tool
     generating the email?

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.)

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.