Date: Wed, 27 Feb 2002 00:40:00 -0800 From: "George V. Neville-Neil" <gnn@neville-neil.com> To: Robert Watson <rwatson@FreeBSD.ORG> Cc: current@FreeBSD.ORG Subject: Re: Discussion of guidelines for additional version control mechanisms (fwd) Message-ID: <200202270840.AAA1409806@meer.meer.net> In-Reply-To: Message from Robert Watson <rwatson@FreeBSD.ORG> of "Tue, 26 Feb 2002 16:53:32 EST." <Pine.NEB.3.96L.1020226165208.28921Z-100000@fledge.watson.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Hi Folks, Before I address Robert's questions directly I'd like to make a few comments. Now, I'm not a committer, I'm a newbie as far as working on FreeBSD itself goes, but I've been a faithful consumer of this stuff since early NetBSD days and was runing Free around 2.2.7. I am also a software engineer with a lot of experience in dealing with OS development and various development models. I spent several years of my time at Wind River being called into meetings on just these subjects, so I do have a bit of a clue and I'm sure that many people out there have similar information but I'd like to put it down in green and black (well whatever colors you've picked...) The problem is NOT (as David Greenman has pointed out) a particular tool. I've used CVS and Clear Case. I have not used Perforce but I know some folks who worked on it and I have a clue as to how it works as well. I find that I like CVS's simplicity but I understand why people could want to use Clear Case as well and I have heard good things about Perforce. In this case I do NOT have a bias about the tools. The problem here is process. The FreeBSD project now has more than 12 core members and more than 12 committers. With any number larger than 12 it is VERY HARD to reach consensus on anything. Without a process by which we agree to reach consensus it is impossible. I read with some amusement the discussion of locks that Robert's email touched off. That discussion showed the group's confusion on this point. Optimally the "tree" would only be locked for such reasons as labelling it, or during a code freeze. Locking sections of it so someone can work on it does not make sense in a distributed project. We'll spend all our time in email doing human locking protocols and will probably lead to more code forking. This is bad. What would a possible solution look like? 1) We need to decide as a group how the framework that supports the OS is broken up and how it is glued together. This is the biggest technical problem, we need to make it so that pervasive changes are not necessary and so that APIs between chunks are either versioned or as static as possible. 2) Once we have areas an area lead will volunteer (probably for a period of time not exceeding a year and not less than 3 months) for each section and be vetted by the core team. 3) The area lead's job is to coordinate all work to be integrated into his/her section on some sort of schedule. We have a 3 times per year release on -STABLE that's a good driver IMHO. We need to do something like that with -CURRENT and perhaps a snapshot schedule should be set up. 4) All locking and release policies come from the above rules as well as the core team and area leads. The problem we are trying to tackle is partly human. How do we coordinate work in a volunteer project and produce a high quality product? It can either be done with a small team, or with fascist techniques (though this does not work well with volunteers) or by lots of cooperation. Now, to answer Robert's questions. > 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 > Email is fine. A pointer to a web page with design docs etc. should also be part of that. > 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 Collapse the two, put that status report on the web (in TWiki?) > Suggestion: Regular status reports on work to relevant mailing lists > Just have a cron job send out the web links in email. > 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 Patches can really suck. You want one main line of development and only have a few small branches for projects. > 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. API changes are most dangerous. The API change should be announced well in advance of committing it so that people who depend on the API can get a clue before they get screwed. > Suggestion: For more minor work, P4 might be used only for brief > collaboration, or to assist in patch preparation. Again, see above, it's not about P4. Well I hope I either offended everyone or no one :-) Later, George -- George V. Neville-Neil gnn@neville-neil.com NIC:GN82 "Those who would trade liberty for temporary security deserve neither" - Benjamin Franklin 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?200202270840.AAA1409806>