On Wed, 27 Feb 2002, George V. Neville-Neil wrote:
> I think we need to avoid the concept of "imposing some modicum of > structure." If we create structure it is because we need it. Just like > software. There was a good comment recently about "software gets > created to scratch an itch." I'd say that structure gets created > because you're tired of losing fingers and toes to the person next to > you wielding the axe. It's great that your friends are helping you > clear the forest but you'd all like to be able to walk and pick up your > cup of coffee at the end of the day as well. What I mean by "imposing structure" is: - Identify patterns of development and structure that seem to have evolved naturally as part of the maturing of the FreeBSD Project - Determine which patterns tend to result in the most productive and parallel development efforts, not to mention which are the most popular - Selectively reinforce those patterns to improve the ability of developers to rely on the patterns An example of this might be investment of time in a rote API change: such changes are time-consuming requiring a lot of brute force source code modification. There's a strong motiviation to avoid redundant work here, but frequently the work is necessary, so it's also desirable to know that it's going to happen. A normal model here might be to look for a developer who's willing to do it, and wait for them to come back in a week or two when it's done. An unproductive tendancy is for four developers to go off, and do the work over two weeks, and all discover they've done it at the end. This can be avoided by making an attempt to coordinate. On a small scale and for individual cases, the "problem" here can be lived with. When it's in the context of a larger piece of work, it can be highly counter-productive. One reinforcement that could be made is to encourage developers to indicate what works in progress they have going, and to encourage other developers interested in a change to give that list a skim to see if someone else has already started on it, and if someone has but appears to be timing out, to encourage them to talk to the developer who has claimed it (in some sense) to find out what is going on. > We are always going to have "first past the post" problems. If someone > comes along and has rewritten a whole subsystem, and testing and > performance measurement show that it's an order of magnitude better > (faster, smaller, etc.) than what we have we'd be idiots not to take it, > right? Obviously. But the contentious cases often aren't the ones where that's the case. > The question is "What processes do we need to put in place to make a > project of this size and dynamisticity work?" I put forward a few of > them. I suggest we start somewhere (including airing gripes people have > with the current system) and write down (i.e. build a web page, use > TWiki) what we're going to do about it. > > I hate to make this analogy but we need a constitution or something like > it. Not so grandiose of course, but a written set of rules and are easy > to interpret that can take care of the 80% case. The 20% we'll always > get to argue over but I'd rather not argue over the 100%. I think we're in the same boat here. You believe that process can help streamline the development process, and be used to help avoid the disagreements we've run into recently (assuming I read you correctly :-). I think so too. I agree we can't bring too much process--that won't work for a large number of reasons. But a little bit of process can go a long way. In particular, I'm looking for a little bit of process that will help address the perceived problems of the current situation. Robert N M Watson FreeBSD Core Team, TrustedBSD Project [EMAIL PROTECTED] NAI Labs, Safeport Network Services To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
