I have a need to provide a stream which has develop as its trunk that can be used for defects found during QA testing. This is fundamentally something completely different from feature development (which is something new rather than something fixed). It is also different from a bugfix since it starts and ends on the current development branch.
I mirrored exactly how the <feature> stream is set up and updated the various help lines where appropriate. I haven't worked out the best way to upgrade an old config, since I now have a new config line for the "defect" stream. Right now, it will just error out when you try any hg flow command (unhelpfully).
If issue 19 was working, I probably wouldn't have to add this, but I still think that defects on the development codeline deserve to be first class objects.
I hate to reject any serious efforts, but on the other hand, I really want to keep this extension as simple as I can.
From my perspective, both fix and feature could mean making something that used to be missing now be available. The only difference is in which state you want to emphasize: If it's the old state: missing or broken, you call it defect; if the new state: available or working, you call it feature. So I would argue that <defect> is essentially the same as <feature> except for the name and therefore it doesn't warrant a whole new stream.
If you really want to separate code changes due to QA testing from others, you may want to consider the option to create a QA branch in <develop>. For example, you can do the following:
Go to <develop>'s trunk.
hg flow develop
Create a branch in <develop> for QA: develop/qa.
hg flow develop start qa
Spin out a feature branch from develop/qa.
hg flow develop/qa:feature start fix_bug1
Finish feature/fix_bug1. Changes merges to develop/qa and then automatically further to the <develop>'s trunk.
hg flow develop/qa:feature finish
Finish develop/qa. All changes in develop/aq will merge to <develop>'s trunk.
I can appreciate your desire to keep the extension simple, but I would argue that differentiating between feature and defect has a number of benefits. For example, in our workflow, all original changes happen on a branch (enforced by pre-commit hook). Only merges are allowed on trunk branches (e.g. develop). When we create a release branch, I can also make the hook forbid feature branches in favor of defect branches.
hg flow release:defect start qa-bug-1
I realize this is just nomenclature and I could just as easily use "feature" there, but by having a distinct name for "defect" emphasises to all parties involved what kind of effort will be taking place on that branch. It is psychological in nature, but having that distiction baked into the tool makes it far more likely that people will do the right thing without having to think about it.
I suspect the correct design would be to rework the code to support custom defined flows (perhaps in the [flow] block of .hgrc) and reimplement the standard flows using that framework (instead of having those definitions embedded in the extension itself). That would simplify the main code and at the same time allow anyone all of the flexibility they could ask for.