Reinier Lamers writes: > Such issues delaying the release are a real problem.
I think that thinking such issues are somehow a release problem is the problem. I think the real problem is letting them be release blockers, ie, allowing such work to be done on the mainline. You should remember that for the great majority of users new features are secondary to bug fixes and general stability. It's only developers who think features are urgent. The underlying reason usually isn't very appetizing, either: the code "needs" to go into the mainline because they want the team to take responsibility for maintaining it. They don't want to have to maintain a local branch indefinitely. I'm all for doing refactoring, but the work that was done here was not of sufficiently high quality to add to the mainline IMO. The people did the work are good and I'm sure they worked hard, but that's not good enough. That is, the bar for adding major changes like these to the mainline should be a lot higher. The comparable application I'm most familiar is Bazaar. They do refactoring like you wouldn't believe, but that stuff often takes a year from the first reasonable publicly-available implementation (usually in a developer's sandbox branch) to recommended upgrade, and even then it may not be the default. Some stuff goes in a lot faster, but somebody has to do one hell of a lot of work to achieve that -- the requirement is almost at "mathematical proof" level for the fast track. In fact, at least *three* somebodies: no new feature goes in without two reviews. Note that they have 3-6 *full-time* employees *plus* a full-time paid project manager (who doesn't even have responsibility for releases -- he worries about process, final decisions when developers disagree, employment, and external contracts). If that's the way a well-funded corporate project works, I think it's unreasonable to hope a "herd of cats" can do better. On the other hand, take XEmacs (which is no poster child for release processes, I must admit, but I'm intimately familiar with it). We're an extremely flexible text editor with a full functional programming language for writing extensions and independent applications. Ie, it's hard to have a release blocker on performance grounds -- the "old way" is almost always still available (sometimes requiring a monkey-patch). Our requirements for stability are *way* lower for this reason. So I think your expectations of stability are way too high for your current process, or alternatively standards for inclusion of code are not high enough. You need to coordinate those, IMO by raising standards for release-ready code, but lowering expectations is also possible (but will undoubtedly cost users in the short run). > 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. That sounds like a problem you should work out with your VCS or day-to-day workflow, not the release process, to me. > 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. That's a non-issue. That's what you *want* to see (as long as those release candidates are scheduled in advance -- of course you don't want to see "final RC" more than once ;-). Note that best practice here is not at all clear, to me, anyway. The highest quality volunteer project I know of is Python; they typically schedule three betas and two RCs (betas at 4 week intervals, RCs at 2 week intervals) for feature releases. Bazaar, OTOH, is moving in the direction of no RCs, just ship the last beta after a couple of weeks with no showstoppers (scheduling a new beta if there are showstoppers). > 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. For a volunteer-developed project, I think that's a sign that the bar for getting changes into the mainline is too low. Starting at least three months before a release containing new features (including refactoring and reimplementation) you need to freeze those features, and ensure that HEAD is approximately releasable at all times up to the release date. Otherwise, you're asking for serious regressions. > We have to commit to a release as a team. Good luck, unless you can either get consulting funding for core Darcs devs, or some corporate users willing to assign some developer time to Darcs support. > 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. This may be a good idea; it's worth trying. However, I think you should schedule features farther in advance. Referring to Bazaar again, they generally have a list going about three minor releases out (informally speaking). Heck, Python is currently in a language moratorium; there will be no changes to the language specification at all for at least one feature release -- new features are allowed only in the standard library. In the language, only bug fixes where the implementation doesn't match the language spec are allowed. That would be like restricting changes in Darcs to the hunk editor. FWIW YMMV Steve _______________________________________________ darcs-users mailing list [email protected] http://lists.osuosl.org/mailman/listinfo/darcs-users
