Date: Sun, 27 Dec 1998 20:58:06 -0800 From: "Jordan K. Hubbard" <jkh@zippy.cdrom.com> To: Warner Losh <imp@village.org> Cc: committers@FreeBSD.ORG Subject: Re: The recent fracas involving danes, war axes and wounded developers Message-ID: <14249.914821086@zippy.cdrom.com> In-Reply-To: Your message of "Sun, 27 Dec 1998 21:44:24 MST." <199812280444.VAA18298@harmony.village.org>
next in thread | previous in thread | raw e-mail | index | archive | help
> 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?14249.914821086>