diff options
| -rw-r--r-- | doc/todo/Better_bug_tracking_support.mdwn | 19 |
1 files changed, 18 insertions, 1 deletions
diff --git a/doc/todo/Better_bug_tracking_support.mdwn b/doc/todo/Better_bug_tracking_support.mdwn index 5bf8a95b2..577da2dc3 100644 --- a/doc/todo/Better_bug_tracking_support.mdwn +++ b/doc/todo/Better_bug_tracking_support.mdwn @@ -9,4 +9,21 @@ The support would not need to be anything fancy, assignment of bug numbers is perhaps the biggest thing missing when compared to a plain wiki page. Integration with the revision control system a la [scmbug](http://www.mkgnu.net/?q=scmbug) would really neat though, so that bug tracker commands like (closes: #nnn) could -be embedded to the source code repository commit messages.
\ No newline at end of file +be embedded to the source code repository commit messages. + +> A while back I posted some thoughts in my blog about +> [using a wiki for issue tracking](http://kitenet.net/~joey/blog/entry/using_a_wiki_for_issue_tracking.html). +> Google's BTS also has some interesting developments along the lines of +> free-form search-based bug tracking, a style that seems a better fit to +> wikis than the traditional rigid data of a BTS. +> +> I sorta take your point about bug numbers. It can be a pain to refer to +> 'using_a_wiki_for_issue_tracking' as a bug name in a place like a +> changelog. +> +> OTOH, I don't see a need for specially formatted commit messages to be +> used to close bugs. Instead, if your BTS is kept in an ikiwiki wiki in +> an RCS along with your project, you can do like I do here, and just edit a +> bug's page, tag it `done`, and commit that along with the bug fix. +> +> --[[Joey]] |