]> sipb.mit.edu Git - ikiwiki.git/commitdiff
web commit by http://harningt.myopenid.com/: IRC discussion about usage semantics
authorJoey Hess <joey@kitenet.net>
Mon, 10 Dec 2007 21:40:27 +0000 (16:40 -0500)
committerJoey Hess <joey@kitenet.net>
Mon, 10 Dec 2007 21:40:27 +0000 (16:40 -0500)
doc/tips/integrated_issue_tracking_with_ikiwiki/discussion.mdwn [new file with mode: 0644]

diff --git a/doc/tips/integrated_issue_tracking_with_ikiwiki/discussion.mdwn b/doc/tips/integrated_issue_tracking_with_ikiwiki/discussion.mdwn
new file mode 100644 (file)
index 0000000..59f0e23
--- /dev/null
@@ -0,0 +1,16 @@
+From IRC messages.. may later format into a nicer display (time is limited):
+
+Just wondering, who's using ikiwiki as their bug-tracking system?  I'm trying to root out bug-tracking systems that work with GIT and so far like ikiwiki for docs, but haven't yet figured out the best way to make it work for bug-tracking.
+
+I suppose having a separate branch for public web stuff w/ the following workflow makes sense:
+
+* Separate master-web and master branches
+* master-web is public
+* cherry-pick changes from master-web into master when they are sane
+* regularly merge master -> master-web
+
+Bug origination point: ... anybody have ideas for this?  Create branch at bug origination point and merge into current upstream branches?  (I guess this would be where cherry-picking would work best, since the web UI can't do this)
+
+Bug naming: any conventions/ideas on how to standardize?  Any suggestions on methods of linking commits to bugs without having to modify the bug in each commit?
+
+-- [[harningt]]
\ No newline at end of file