Robert Watson, of the core FreeBSD team, recently sent a message to the 'Current' FreeBSD mailing list, looking to initiate a constructive discussion to develop guidelines for the use of source control software beyond the main CVS repository. The end goal to create "a set of recommendations to maximize communication and acceptance by the broader community".
This is in response to recent lengthy discussion of the many source code repositories used, and the lack/difficulty of communication between all involved as to what's where. Robert's full email follows.
From: Robert Watson To: current at FreeBSD.ORG Subject: Discussion of guidelines for additional version control mechanisms Date: Sat, 23 Feb 2002 16:28:47 -0500 (EST) In the past week, a number of comments have been made both for and against additional version control mechanisms being used to supplement the FreeBSD Project official CVS server. Proponents of additional mechanisms, such as Perforce, have pointed out that CVS doesn't provide the necessary tools to support several important development models, including those based on light-weight branching and three-way merges. Others have pointed out that while these technical benefits might be real, the resulting decentralization can be a problem for the project, and that requiring additional version control mechanisms in order to work with the project is simply not feasible. For the purpose of this discussion, please assume that additional version control facilities serve a useful purpose (by supporting collaboration, tree tracking, etc), but that [not] everyone will be able to use them, both based on preference, and for technical and material reasons. The purpose of this message is to initiate a serious discussion of what guidelines might be put in place to help facilitate the use of additional version control mechanisms (which are inevitable, even if it means only individual developers with local CVS repositories of their own), and how to specifically address the problems that have been posed, in particular relating to communication. The outcome of this conversation will probably not be a set of rules: there is sufficient variation in the nature of various sub-projects that it wouldn't make sense. However, it will result in a set of recommendations to maximize communication and acceptance by the broader community. I've mixed in some suggested things to think about as possible answers, but there are probably many more things to consider. Question 1: How should the presence of on-going work in an external repository be announced to the broader community? Suggestion: e-mail to -arch, -current, or a related mailing list Question 2: How should the status of on-going work be announced to the broader community? Suggestion: Bi-monthly developer status report Suggestion: Status web page for the project Suggestion: Regular status reports on work to relevant mailing lists Question 3: How should the results of the on-going work be made available to the broader community? Suggestion: cvsup10 export of the Perforce tree Suggestion: patchsets sent to appropriate mailing lists with status Suggestion: patchsets generated automatically and posted to the mailing list Question 4: How agressively should on-going work be pushed back into the base tree? (Note that the answer here depends a great deal on the nature of the work: both its rationale, its goals, etc). In particular note that currently Perforce is used to hold experimental changes, as well as ones destined for eventual production use. Suggestion: For work requiring large source tree sweeps, API changes, etc, only when the work is ready to commit. Suggestion: For more minor work, P4 might be used only for brief collaboration, or to assist in patch preparation. It's worth noting before getting into too much discussion that there's a spectrum of possibilities, and different answers may be appropriate for different circumstances. If P4 is not used as a collaboration tool, only for local version management for individual developers, it serves the same purpose as any local source tree. Likewise, at low levels of collaboration, it's no different from mailing patchsets. As the level of collaboration increases, the failed balancing point seems to be in providing access to non-P4 users. It might be useful to look at this discussion through a series of case examples, including projects such as KSE, SMPng, OpenPAM, TrustedBSD, architecture ports such as ia64, sparc64, etc.Robert N M Watson FreeBSD Core Team, TrustedBSD Project
NAI Labs, Safeport Network Services