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.
 
 
 
 
 

57 lines
2.2 KiB

  1. TODO list for reportbug 4.0 (squeeze):
  2. 0. revisit README.{developers,source} for source code layout section
  3. 0.1. fix the way reportbug/querybts obtain a UI: the ideal would be to
  4. use getUI from reportbug.ui, since the module already has all the
  5. UIs loaded (to know the ones available).
  6. bin/reportbug - line 833
  7. bin/querybts - line 174
  8. 0.3. reportbug/ui/text_ui.py
  9. + disabled utils.NEWBIELINE check to avoid circular import between text
  10. and utils ******** WE NEED TO FIND A SOLUTION TO THIS **********
  11. 0.4. check for utf-8/weird locales errors, maybe at
  12. http://ginstrom.com/scribbles/2008/11/16/notes-for-using-unicode-with-python-2x/
  13. we can find some hints?
  14. 0.5. remove the tmp file only after the report is actually sent (or at least it
  15. should be configurable?)
  16. 0.6. bin/reportbug: refactor the package name check/get/verify or so (now it's
  17. sparse all around the file
  18. 0.7. what's the difference between 'X-Mailer' (as used by reportbug) and
  19. 'User-Agent' (as used by bts)? what's preferred to identify the tool
  20. generating the email?
  21. 3. BTS management interface for developers. You should be able to
  22. view the list of bug reports for a package, construct a list of
  23. actions, and produce one giant email to control@bugs.debian.org to
  24. do that. Forwarding and merging, which both can be major PITAs,
  25. will be helpful. (See #157283)
  26. ("devscripts" has the bts command. This is hence a very low priority.)
  27. 4. i18n/l10n.
  28. (i18n/l10n with reportbug may not make much sense, since the
  29. reports have to be in English for most maintainers to understand
  30. them... unless we figure out some way to get bug reports translated
  31. for maintainers.)
  32. 7. Allow followups from the command line using a specific bug number,
  33. rather than requiring people to go through the browser. Coupled
  34. with --query-only, this should allow me to drop querybts
  35. completely. (See #223335)
  36. 8. Optionally display changelogs for new upstream versions.
  37. (See: #241552) Perhaps it should cooperate with apt-listchanges
  38. somehow to do this?
  39. 9. Improve MUA code to allow arbitrary arguments to MUAs; see #271084.
  40. 10. Multiple BTS support (again), which probably means "Bugzilla
  41. support" for Ubuntu, etc.