it helps to distinguish some use cases

[git.ikiwiki.info.git] / doc / todo / Better_bug_tracking_support.mdwn

diff --git a/doc/todo/Better_bug_tracking_support.mdwn b/doc/todo/Better_bug_tracking_support.mdwn
index 577da2dc31e8a58d25c598271a08b46ad503bf91..1a810ad5583cd64ff149ed39863fdd0ea0b5cb75 100644 (file)
--- a/doc/todo/Better_bug_tracking_support.mdwn
+++ b/doc/todo/Better_bug_tracking_support.mdwn
@@ -20,10 +20,52 @@ be embedded to the source code repository commit messages.
 > 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.
 > 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.

-> 
+
+>> Would a modified [[plugins/inline]] plugin that allowed new pages, but without a title field, be ok?
+>> When you hit the edit button it just chooses a new number and makes a page with that
+>> name.
+
+>> The only issue I can see with this is if you're using a distributed wiki for
+>> distributed bug tracking.  In that case you're going to have to make sure that you
+>> don't get conflicting bug ids.
+>> Maybe there should be two options - consecutive numbering, and uuid numbering
+>> which uses a random (128 bit, base64 encoded = 22 chars) name. -- [[Will]]
+

 > 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]]
 > 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]]

+
+>> I think a little bit more structure than in a normal wiki would be
+>> good to have for bug tracking. Bug numbers, automatic timestamps on comments
+>> and maybe an email interface would be nice. The resulting page may not 
+>> look like a wikipage anymore, but rather something like the Debian 
+>> BTS web-interface, but it would still benefit from wikilinks to the 
+>> documentation in the wiki etc.
+
+>>> I think it is useful to look at these things separately:
+>>>
+>>> * Bug numbers: See above.
+>>> * Automatic timestamps on comments: this already exists with the inline directive.
+>>> * Email interface: You can certainly get an rss feed of what changes in the wiki.
+>>> * You didn't mention [[todo/structured_page_data]] but that is, I think, part
+>>>     of what you seem to be saying.
+>>> * [[todo/tracking_bugs_with_dependencies]] is also important.
+>>>
+>>> -- [[Will]]
+
+>> About the commit message interface: I was thinking about a project
+>> architecture where the code is kept in a separate revision control
+>> system branch than the metadata (blog, wiki, BTS). This would IMHO
+>> be a cleaner solution for distributing the source and making releases
+>> etc. For this kind of setup, having the BTS scan the messages of the 
+>> source branch (by a commit-hook for example) would be useful.
+>>
+>> By Google BTS, do you mean the issue tracker in the Google code 
+>> project hosting?
+>>
+>> --Teemu
+
+[[wishlist]]