urosm
/
ikiwiki
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

response

master
joey 2007-03-21 19:26:23 +00:00
parent 12d947a02f
commit 0daec2bf14
1 changed files with 18 additions and 1 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

17
doc/todo/Better_bug_tracking_support.mdwn
View File

@ -10,3 +10,20 @@ 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) 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 would really neat though, so that bug tracker commands like (closes: #nnn) could
be embedded to the source code repository commit messages. 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]]