FogBugz and Kiln Seminar

Here are my notes from FogCreek’s recent FogBugz and Kiln World Tour stop in Toronto (thanks to Gordon Cameron for the ticket!):

FogCreek FogBugz and Kiln

FogBugz is an application lifecycle management tool (think bug tracker on steroids). Based around issues within projects, and developers working on those issues, providing estimates, etc.

  • web app platform, hosted either on site or at FogCreek


  • schedule -> monte carlo, evidence based project scheduling simulation & prediction (requires corpus of 6 features per developer for prediction to work), incorporates blocking/deadlock detection
  • test case management with issues and tags
  • requirement & feature management with issues and tags
  • sophisticated reporting and visualization
  • hierarchical issue structure
  • extremely close integration with Kiln
  • fogbugz agile features: burndown charts (monte carlo based), backlog management, kanban support
  • commercial (non-free) software

answer question “is fix X in version Y?”

Kiln is a software management tool built on top of Mercurial. Provides a web interface to track, manage, and understand code and repositories of code.
“kiln tracks code like fogbugz tracks projects”


  • manage multiple mercurial repositories from a single interface
  • easily search & navigate code online
  • server-side blob support – reduce checkout & history size
  • has permission system for server-side repo push-pull
  • build & continuous integration support & hooks
  • code review feature
  • extremely close integration with FogBugz
  • compatible with all mercurial tools & plugins

dvcs equivalent to changesets?? wtf? that’s not distributed

DVCS University


  • see
  • metaphor: a changeset is like a transparent animation cell – stacking them together and looking down through the stack is the current version – can be reordered, moved, deleted easily
  • server & local repo usage is equivalent to private branches


fixes in old releases

  • traditionally, a bug found in an old version needed to be fixed many times – once in each release branch of your product
  • with mercurial changesets, this process is easier, as a changeset applied to an old version can propagate forward through the changeset stack with minimal merge conflicts

custom client releases

  • creating a ‘one-off’ version of your product is now easy
  • have 2 hg repositories – one for official, one for client version
  • fixes and features from official release repo can be easily pushed to custom client release repo
  • keep custom repo downstream of offical repo
  • could have used a named branch, but hg branching has weird workflow – can’t easily remove named branch, but can delete repo, new repo is easier to understand than a new branch – learning curve
  • applies changesets from one repo to the other, applied after a point in time, instead of applying absolute diff between two latest versions of content – ie. the custom features won’t show up in the merge

It's only fair to share...
Share on Facebook
Tweet about this on Twitter
Share on LinkedIn

Leave a Reply