From owner-cvs-all Sun Jan 10 11:26:36 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id LAA02801 for cvs-all-outgoing; Sun, 10 Jan 1999 11:26:36 -0800 (PST) (envelope-from owner-cvs-all@FreeBSD.ORG) Received: from rover.village.org (rover.village.org [204.144.255.49]) by hub.freebsd.org (8.8.8/8.8.8) with SMTP id LAA02793 for ; Sun, 10 Jan 1999 11:26:31 -0800 (PST) (envelope-from imp@village.org) Received: from harmony [10.0.0.6] by rover.village.org with esmtp (Exim 1.71 #1) id 0zzQUe-0000rq-00; Sun, 10 Jan 1999 12:25:48 -0700 Received: from harmony.village.org (localhost.village.org [127.0.0.1]) by harmony.village.org (8.9.1/8.8.3) with ESMTP id MAA12437; Sun, 10 Jan 1999 12:23:50 -0700 (MST) Message-Id: <199901101923.MAA12437@harmony.village.org> To: Julian Elischer Subject: Re: sysctl descriptions Cc: committers@FreeBSD.ORG In-reply-to: Your message of "Sun, 10 Jan 1999 02:25:46 PST." References: Date: Sun, 10 Jan 1999 12:23:50 -0700 From: Warner Losh Sender: owner-cvs-all@FreeBSD.ORG Precedence: bulk In message Julian Elischer writes: : how does one apply to core for an un-nuking of a nuke by core? Speaking hypothetically... First one would try to reach an agreement with that committer (core or not). This is always the most desirable way to resolve a conflict over source in the tree. If I couldn't negotiate with the core member, I'd likely un-nuke it myself and make them justify their actions. I'd also listen to the consensus of FreeBSD developers and if they were against the change I'd either let the nuking stand, or re-nuke it myself. Personally I feel that if there is a change that no one wants, it is up to the original changer to nuke it, not some core member. This is Jordan's "shooting your own dog" doctorine. I know I've shot many of my own dogs this way. If things escelated into a commit war, I'd send something to core and see what happened. If they mediated the dispute, I'd live by their mediation. If nothing happened, I'd likely continue the commit war until either the core member or myself lost commit privs to show just how silly things had gotten. The continuation would likely only happen if my input was being ignored and not answered in a technical way. It would take a lot to get me to continue a commit war, don't get me wrong: It is the vehicle of last resort. At each step I'd try to reach a diplomatic solution based on consensus. Just because a core member makes a commit doesn't mean it is any better or any worse than my (or any other committer) making a commit. There may be other factors as well, but core status alone doesn't give one a cloak of infalibility in and of itself. There is no reason to feel intimidated by a core member just because they are a core member. All of the above assumes that the change worked, made good technical sense and was apparently wanted by a large number of committers and no serious technical objects had been raised to the commit. If there are technical reasons, then it would be more important to reach a good consensus about them before proceeding. It is basically what I'd do if there was one, and only one, core member tying to use his core status to blackball a change that the rest of the committers favored. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe cvs-all" in the body of the message