Date: Fri, 6 Feb 1998 04:45:51 +0100 From: Eivind Eklund <eivind@yes.no> To: "Daniel O'Connor" <doconnor@gsoft.com.au> Cc: cvs-committers@FreeBSD.ORG Subject: Re: cvs commit: src/sys/conf files Message-ID: <19980206044551.64694@follo.net> In-Reply-To: <199802060318.NAA27642@cain.gsoft.com.au>; from Daniel O'Connor on Fri, Feb 06, 1998 at 01:48:17PM %2B1030 References: <19980206040948.49901@follo.net> <199802060318.NAA27642@cain.gsoft.com.au>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, Feb 06, 1998 at 01:48:17PM +1030, Daniel O'Connor wrote: > > > There are good sides of their model, too - you have a centralized > > place to throw changes at, and the person taking care of that area > > have to either reject or accept - ignoring is not really an option. > Whats the difference between that, and me just mailing a committer > (or -current) with my groovy new patch? There is little difference between that and personal mail to a committer. There is a world of difference between it and mailing to -current. > The central person in the Linux model could just ignore it (like > what happens on -current ;) No, he couldn't. Not as easy, anyway. In mailing -current, not handling a patch drops down to being Somebody Elses Problem - nobody is responsible. For personal mail, things end up as the responsibility of a single individual, who knows that unless (s)he takes care of it, it will not be taken care of. I believe this is the single place where there is most room for improvement for FreeBSD. Ways to leverage include (but is not limited to): - Make freebsd-questions a moderated mailing list with a large set of round-robin moderators - perhaps 20 or 50 moderators. Each moderator take responsibility for answering the questions coming in to her to the best of her ability. If she can't give an answer she believe to be wholly satisfactory, she approve the question for a larger audience. - Repeat above procedure, but for the bugs list/send-pr system. Here assignement should either be to volunteering committers, or to a set of front-line people that are responsible for vetting and (if necessary) sending patches on to the right committer for the area. - Create a bond between a single committer and an outside developer, letting the outside developer use the committer as a gateway to getting his material evaluated/committed. (The mentor project I've proposed earlier - I'm still willing to write up and do everything to get it rolling if I actually get any other committers that seem to be in favour.) The point is that everything must end up as the personal responsibility of a single person. "Somebody" usually end up as "nobody". And we have this problem almost everywhere, including "the" security-officer (which I've mailed without getting an answer from). Eivind.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?19980206044551.64694>