Date: Mon, 28 Dec 1998 15:28:59 -0800 (PST) From: Julian Elischer <julian@whistle.com> To: "Jordan K. Hubbard" <jkh@zippy.cdrom.com> Cc: Warner Losh <imp@village.org>, committers@FreeBSD.ORG Subject: Re: The recent fracas involving danes, war axes and wounded developers Message-ID: <Pine.BSF.3.95.981228152824.20004G-100000@current1.whistle.com> In-Reply-To: <14249.914821086@zippy.cdrom.com>
next in thread | previous in thread | raw e-mail | index | archive | help
yeah is this retrospective? :-) On Sun, 27 Dec 1998, Jordan K. Hubbard wrote: > > So what have we learned? Can you be more specific so that those of us > > not on core will know how to handle things like this in the future? > > IE I want to kill GerbilFS, which is badly rotted, what are the > > criteria for its death and what is the proceedure to make sure that > > things doen't get as bloody as FreeBSD's recent purge. > > Sorry, this is another issue a number of us just discussed and came to > a preliminary ruling on - I didn't have an answer to your question > just 5 minutes ago or I'd have put it on my "timeline" :-) > > The criteria for the death of bits in FreeBSD from now on, according > to David Greenman, our principal architect and general guy in charge > of tie-breaking decisions when such are necessary, is that it be done > directly by original author/committer of the bits (and not by any > arbitrary 3rd party) unless, and only unless, a *unanimous* core team > vote for its removal is made. Such a vote would be preceded by a 72 > hour discussion period, during which time committers list would be > also brought into the discussion in order to express their opinions, > the final decision still being up to the core team and its vote. > > I personally think that's the only truly fair way to go about this in > the future and also it fits nicely with dictum that "a man should > always shoot his own dog" - if someone commits something that turns to > dreck then they should be the ones to clean it up when the time > comes. There will be the occasionally necessary exceptions, of course, > such as when an author designates a proxy to do the deed on his behalf > due to other time pressures, or when something gets yanked for driving > technical reasons (major security flaw, entirely superceded by other > functionality, etc), but this is the basic idea. > > Comments? > > - Jordan > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe cvs-all" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.3.95.981228152824.20004G-100000>