[darcs-users] On Release Management
tux_rocker at reinier.de
Sun Nov 7 14:23:35 UTC 2010
As the parting release manager I'd like to share some thoughts on the darcs
The 2.4 and 2.5 release processes have been regarded as painful. Just before a
final 2.4 would go out the door, we'd find a release blocking bug. We fixed
the bug, and released a new release candidate, and then just before we would
release 2.4 final, we found another bug. And the cycle repeated. Similarly,
during the 2.5 release cycle, we discovered some regressions caused by the
NewSet or noslurps changes, like http://bugs.darcs.net/issue1951.
During the 2.5 release cycle, we were sometimes waiting for 2 weeks for work
to be done on release-critical bugs. http://bugs.darcs.net/issue1942 and
http://bugs.darcs.net/issue1951 are examples.
Such issues delaying the release are a real problem. The longer a release
branch is separated, the harder it will be to merge fixes from HEAD into the
release branch and to merge the tags from the release branch back into HEAD.
Also, I am afraid that pushing out release candidates with 2 or 3 weeks
between them with very little changes does not make us look like a vibrant
We hope to address the problem of lots of regressions being found by doing
alpha releases whenever big changes are merged into HEAD. But the problem of
release-critical bugs not being picked up remains.
I think we have to change our approach to releases to make future releases go
more smoothly. The idea that the release manager just takes the current state
of HEAD, fixes a couple of small bugs reported by beta users and announces a
stable release doesn't work. We have to commit to a release as a team.
That means that when we are in a release cycle, the release should be the most
important darcs issue for all developers. When a release-critical regression
is discovered, it should be picked up in a couple of days, not weeks. If a
regression is discovered that was introduced by your code, it's time to drop
other darcs things you are working on and fix it right away.
The problem with such an approach is that we are all volunteers. There is no
way a Release Manager can order you to work on something or to work at all.
Still, perhaps we can increase people's commitment to releases by making them
more feature-based than they are now.
So instead of saying that we release darcs 2.X at time Y with whatever
features are ready by then, we make a realistic list of features that should
be in a new darcs release well in advance[*]. We could make a list of features
for the next release immediately after every minor release. I hope that if we
have a concrete idea of what the next darcs release will look like, we will be
more focused to deliver it.
Now I realize that these ideas conflict with the current darcs culture, and I
also realize that it remains to be seen if I can practice what I preach next
to my day job. Still I'm interested in hearing your opinions.
[*]: I am heavily borrowing here from the Agile/SCRUM planning approach that I
use at work
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 198 bytes
Desc: This is a digitally signed message part.
More information about the darcs-users