Date: Sun, 10 Jan 1999 12:23:50 -0700 From: Warner Losh <imp@village.org> To: Julian Elischer <julian@whistle.com> Cc: committers@FreeBSD.ORG Subject: Re: sysctl descriptions Message-ID: <199901101923.MAA12437@harmony.village.org> In-Reply-To: Your message of "Sun, 10 Jan 1999 02:25:46 PST." <Pine.BSF.4.05.9901100223440.3712-100000@s204m82.isp.whistle.com> References: <Pine.BSF.4.05.9901100223440.3712-100000@s204m82.isp.whistle.com>
next in thread | previous in thread | raw e-mail | index | archive | help
In message <Pine.BSF.4.05.9901100223440.3712-100000@s204m82.isp.whistle.com> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199901101923.MAA12437>