summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorjoey <joey@0fa5a96a-9a0e-0410-b3b2-a0fd24251071>2007-03-21 19:26:23 +0000
committerjoey <joey@0fa5a96a-9a0e-0410-b3b2-a0fd24251071>2007-03-21 19:26:23 +0000
commit0daec2bf14871072a4b3d3aebbbfc5eaa7608ef5 (patch)
tree5e4d4debfeb7f7781763505bd2ef00052cfb992c
parent12d947a02f2feacc6524851a40751767f04bb48d (diff)
response
-rw-r--r--doc/todo/Better_bug_tracking_support.mdwn19
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]]