[darcs-users] On Release Management

Reinier Lamers tux_rocker at reinier.de
Sun Nov 7 14:23:35 UTC 2010


Hi all,

As the parting release manager I'd like to share some thoughts on the darcs 
releases process.

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 
project.

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.

Reinier

[*]: 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
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.osuosl.org/pipermail/darcs-users/attachments/20101107/9f52538c/attachment.pgp>


More information about the darcs-users mailing list