Apparently a number of people missed this post, so I'm resending. To recap: this is an attempt to brainstorm for ideas about how we can improve our use of version control, while responding to concerns about access the resulting work. The goal is to formulate a set of guidelines based on whatever suggestions come out of this work.
Robert N M Watson FreeBSD Core Team, TrustedBSD Project [EMAIL PROTECTED] NAI Labs, Safeport Network Services ---------- Forwarded message ---------- Date: Sat, 23 Feb 2002 16:28:47 -0500 (EST) From: Robert Watson <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] Subject: Discussion of guidelines for additional version control mechanisms 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 no 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 [EMAIL PROTECTED] NAI Labs, Safeport Network Services To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message