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