Before I address Robert's questions directly I'd like to make a few
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
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
these subjects, so I do have a bit of a clue and I'm sure that many people out
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
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
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
-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
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 :-)
George V. Neville-Neil [EMAIL PROTECTED]
"Those who would trade liberty for temporary security deserve neither"
- Benjamin Franklin
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message