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, maybe at
     http://ginstrom.com/scribbles/2008/11/16/notes-for-using-unicode-with-python-2x/
     we can find some hints?

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?

1. (We have one, but it needs to be updated.) 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. (In progress.)  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. (This is already done, I believe.) Convert BTS code to use the
   mbox-format reports if available, as they should be easier to
   parse.

6. (SOAP is here, we need to integrate it.)  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.
