git.oblomov.eu Git - ikiwiki/blob - doc/todo/Better_bug_tracking_support.mdwn

   1 I see that ikiwiki has already some [[bugs]] stored on the wiki, but adding
   2 better support for bug tracking would really make it a good project
   3 management system for small projects. Storing the sourcecode, wiki, developer
   4 blog and the issue tracker information under a same revision control
   5 system really makes sense. At the moment the only part missing from ikiwiki
   6 is the bug tracker plugin.
   7
   8 The support would not need to be anything fancy, assignment of bug numbers
   9 is perhaps the biggest thing missing when compared to a plain wiki page.
  10 Integration with the revision control system a la [scmbug](http://www.mkgnu.net/?q=scmbug)
  11 would really neat though, so that bug tracker commands like (closes: #nnn) could
  12 be embedded to the source code repository commit messages.
  13
  14 > A while back I posted some thoughts in my blog about
  15 > [using a wiki for issue tracking](http://kitenet.net/~joey/blog/entry/using_a_wiki_for_issue_tracking.html).
  16 > Google's BTS also has some interesting developments along the lines of
  17 > free-form search-based bug tracking, a style that seems a better fit to
  18 > wikis than the traditional rigid data of a BTS.
  19 >
  20 > I sorta take your point about bug numbers. It can be a pain to refer to
  21 > 'using_a_wiki_for_issue_tracking' as a bug name in a place like a
  22 > changelog.
  23 >
  24 > OTOH, I don't see a need for specially formatted commit messages to be
  25 > used to close bugs. Instead, if your BTS is kept in an ikiwiki wiki in
  26 > an RCS along with your project, you can do like I do here, and just edit a
  27 > bug's page, tag it `done`, and commit that along with the bug fix.
  28 >
  29 > --[[Joey]]
  30
  31 >> I think a little bit more structure than in a normal wiki would be
  32 >> good to have for bug tracking. Bug numbers, automatic timestamps on comments
  33 >> and maybe an email interface would be nice. The resulting page may not
  34 >> look like a wikipage anymore, but rather something like the Debian
  35 >> BTS web-interface, but it would still benefit from wikilinks to the
  36 >> documentation in the wiki etc.
  37 >>
  38 >> About the commit message interface: I was thinking about a project
  39 >> architecture where the code is kept in a separate revision control
  40 >> system branch than the metadata (blog, wiki, BTS). This would IMHO
  41 >> be a cleaner solution for distributing the source and making releases
  42 >> etc. For this kind of setup, having the BTS scan the messages of the
  43 >> source branch (by a commit-hook for example) would be useful.
  44 >>
  45 >> By Google BTS, do you mean the issue tracker in the Google code
  46 >> project hosting?
  47 >>
  48 >> --Teemu
  49
  50 [[wishlist]]