Date: Tue, 26 Feb 2002 21:23:36 -0500 From: Garance A Drosihn <drosih@rpi.edu> To: Robert Watson <rwatson@FreeBSD.ORG>, current@FreeBSD.ORG Subject: Re: Discussion of guidelines for additional version control mechanisms (fwd) Message-ID: <p05101401b8a1ee73f02d@[128.113.24.47]> In-Reply-To: <Pine.NEB.3.96L.1020226165208.28921Z-100000@fledge.watson.org> References: <Pine.NEB.3.96L.1020226165208.28921Z-100000@fledge.watson.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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 = gad@eclipse.acs.rpi.edu Senior Systems Programmer or gad@freebsd.org Rensselaer Polytechnic Institute or drosih@rpi.edu To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?p05101401b8a1ee73f02d>