At 4:53 PM -0500 2/26/02, Robert Watson wrote:
>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 [...].  I've mixed
>in some suggested things to think about as possible answers, but
>there are probably many more things to consider.

I think this is a good topic for people to think seriously about.
I think it is valuable that some people are trying alternatives
to CVS for doing "freebsd work", because almost all of us are
unhappy with some aspects of CVS.  Someone has to learn how
well a prospective alternative will work with *this* project,
or we're going to be forever stuck with CVS.

>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

I think these are the less-important questions.

>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

This is more important.  If someone is using system <not-CVS> for
a change, then it damages the project if other people *must* learn
that system to find out what is happening with the change.  Most
of the people who are really interested in some change will want
to see the specific code patches for that change.  Status reports
are no substitute for reviewing the actual code.

Note that I am not suggesting an answer, I'm just saying this is
an important question...   :-)

>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.

I think the main issue here is how long the real repository can be
"locked" while waiting for some change to show up.  If work can
keep going into the main repository, then what does anyone care
if someone is tracking their own personal work using CVS, or
perforce, or a bunch of home-grown shell scripts?

Garance Alistair Drosehn            =   [EMAIL PROTECTED]
Senior Systems Programmer           or  [EMAIL PROTECTED]
Rensselaer Polytechnic Institute    or  [EMAIL PROTECTED]

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Reply via email to