Jake> I beleive that XEmacs has a similar situation where Jake> different forms of development happen in parallel yet Jake> eventually must be merged into a common HEAD. How does Jake> XEmacs manage this? First, by modularization. The package system has allowed us to desynchronize several lines of development that used to be dependent. Eg, at this point GNU Emacs 20 is using a Gnus version that is more than two years behind their core. I assume they'll catch up with the release of Emacs 21, then start to lag again. This aspect of packages has been spectacularly successful, and it was intended by the package system designers and implementers. Obvious, but it may be worth investing in more modularization in your own products. In the core, we don't actually "manage" parallel development. Bill Perry (GTK), Ben Wing (various), and Michael Sperber (GC, being designed and implemented by his student Richard Reingrub) have informally taken the initiative to create branches. Branch creation for this purpose is supported by Review Board. But we don't have a formal policy on "how big" a project needs to be before being treated as a branch. I think 21.4.x is suffering from this because of "medium-size" changes to Customize that were incomplete as of the release of 21.4. (This is an ex-post observation, not a complaint.) We also don't have a formal process to decide when to merge. I think it would be a good idea to have both a fairly stringent criterion for branching (ie, relatively small projects should be done on branches), and a formal process (and probably a manager with specific decision authority) for timing the merges. But process management is a large burden, both in time and emotional energy, for a distributed, fairly democratic, project like XEmacs. I think both burdens can be much reduced in a business. However, you need to budget for time costs of more branching (and/or developing tools to automate branch creation, maintenance and tracking) and the coordination of merges. Jake> It would seem that one approach would be to create multiple Jake> development branches, one for each project. As a project is Jake> completed, it is merged to the HEAD. Releases are also done Jake> from the HEAD. Note that in fact XEmacs now does _no_ releases from HEAD. When we decide to do a release, we make a branch. That is, we have release branches (which are in principle feature-frozen) and development branches for destabilizing projects. The timeline for a given project is proposal -- develop on a project branch -- merge to HEAD -- release on a release branch -- bug fixes on the release branch. Any further development of the project takes place on HEAD (unless it's a destabilizing rewrite, or a huge new feature). Jake> My concern is with the management of merges down from the Jake> HEAD to a particular develpoment branch. So far, it hasn't been a problem for us. For me, managing a release branch, it's been tolerable (since I got a Windows build platform to aircheck ports of Windows stuff from HEAD to 21.4---patches often apply with no warnings, but are incomplete)---and I am not an experienced programmer. Ben has occasionally remarked on the amount of work he puts into HEAD-to-project-branch merges, but my interpretation of that is he's explaining why these things take time. I know Michael Sperber's student, Richard Reingrub, who works on GC, does these merges regularly. No complaints from that quarter. Tomohiko Morioka, who has actually forked his UTF-2000 version of XEmacs, also does such merges, treating them as routine. Also, note that the smaller the project, proportionally less burden would be imposed by such merges. So this is not a barrier to putting smaller projects on branches. So my feeling is that (1) you have to do such merges and (2) the main issue in management is to budget for them sensibly. Michael, Richard, or Ben may have further useful comments. -- University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN Institute of Policy and Planning Sciences Tel/fax: +81 (298) 53-5091 _________________ _________________ _________________ _________________ What are those straight lines for? "XEmacs rules."