Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 27 Dec 1998 21:05:58 -0800
From:      Mike Smith <mike@smith.net.au>
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:  <199812280505.VAA07578@dingo.cdrom.com>
In-Reply-To: Your message of "Sun, 27 Dec 1998 20:58:06 PST." <14249.914821086@zippy.cdrom.com> 

next in thread | previous in thread | raw e-mail | index | archive | help
> 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 don't like this; it grants any single core member power of veto, and 
that's a current problem with our system already.

If you raise your eyes a few inches to the way that this sort of 
politicised issue is dealt with in much larger organisations, something 
like this arises:

 - The removal of an item should be raised publically, with some 
   closing period for discussions set.  I think 72 hours is a suitable
   minimum.
 - If at the closing of the discussions, there is a clear mandate for
   removal, it should proceed.
 - If there is no clear mandate for removal, the matter should be taken 
   to -core *OR* some other body, perhaps comprised of more active 
   developers.
 - This body's vote should use contemporary methods; voting requires 
   quorum, and a motion is carried by "obvious majority" - in our case,
   probably around 60-80%.
 - There should be a process for popular appeal of a decision; either 
   for an expanded explanation, or for a re-vote.
 - The adjudication body's discussions should be world-readable.

> 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.

These functions require the existence of executive power, or 
corresponding process.  The former requires a trusted executive 
(Americans, look to your presidential history for how not to do this), 
the latter may be more odious than we are willing to bear.

-- 
\\  Sometimes you're ahead,       \\  Mike Smith
\\  sometimes you're behind.      \\  mike@smith.net.au
\\  The race is long, and in the  \\  msmith@freebsd.org
\\  end it's only with yourself.  \\  msmith@cdrom.com



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?199812280505.VAA07578>