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
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ darcs-users mailing list [email protected] http://lists.osuosl.org/mailman/listinfo/darcs-users
