doc/tips/integrated_issue_tracking_with_ikiwiki/discussion.mdwn

   1 From IRC messages.. may later format into a nicer display (time is limited):
   2
   3 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.
   4
   5 > I know of only a few:
   6 > * This wiki.
   7 > * The "awesome" window manager.
   8
   9 I suppose having a separate branch for public web stuff w/ the following workflow makes sense:
  10
  11 * Separate master-web and master branches
  12 * master-web is public
  13 * cherry-pick changes from master-web into master when they are sane
  14 * regularly merge master -> master-web
  15
  16 > That's definitely one way to do it. For this wiki, I allow commits
  17 > directly to master via the web, and sanity check after the fact. Awesome
  18 > doesn't allow web commits at all.
  19
  20 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)
  21
  22 > Not sure what you mean.
  23 >> Documentation as to where the bug came from for related branches...
  24 >> Ex: The bug got located in r30, but really came about r10.  Desire is to propagate the bug to all everything after r10.
  25
  26 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?
  27
  28 > I don't worry about naming, but then I don't refer to the bug urls
  29 > anywhere, so any names are ok. When I make a commit to fix a bug, I mark
  30 > the bug done in the same commit, which links things.
  31
  32 -- [[harningt]]