From owner-freebsd-arch Thu May 2 14:16:32 2002 Delivered-To: freebsd-arch@freebsd.org Received: from falcon.prod.itd.earthlink.net (falcon.mail.pas.earthlink.net [207.217.120.74]) by hub.freebsd.org (Postfix) with ESMTP id C2CEE37B41A; Thu, 2 May 2002 14:16:27 -0700 (PDT) Received: from pool0524.cvx21-bradley.dialup.earthlink.net ([209.179.194.14] helo=mindspring.com) by falcon.prod.itd.earthlink.net with esmtp (Exim 3.33 #2) id 173Nw9-0003cm-00; Thu, 02 May 2002 14:16:26 -0700 Message-ID: <3CD1AC8D.25458679@mindspring.com> Date: Thu, 02 May 2002 14:15:57 -0700 From: Terry Lambert X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: arch@FreeBSD.org Cc: John Baldwin Subject: Re: savcore dump names? References: <20020502133256.A40128@dragon.nuxi.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG David O'Brien wrote: > On Thu, May 02, 2002 at 02:02:29PM -0400, John Baldwin wrote: > > So what happened to the request that savecore(8) go back to using > > sensible, intuitive names instead of brain-damaged ones? > > The committer that took that feature away isn't interested in seeing > things through to the end. > > Another reason we need an owner of each thing in the tree. So that if they get hit by a bus, we're screwed for all time? So that if anyone wants to make a change, and there's no way the owner can pee on it to make it smell like them, the change doesn't have a snowball's chance in hell of making it in? It's a really *bad* idea to have things set up so that people are so emotionally invested in their code -- or the status quo -- that they can't see anything else. Not to harp on you in particular, but your statement about "isn't interested in seeing things through" is really emotionally charged, and is exactly the wrong sort of thing. The ideal gatekeeper for any code is someone who doesn't even use the code, or is a user, not a coder, for it. Then you will get decisions based on logic rather than emotion. I think the obvious thing to do is to wait a while for the code to be completed, and then time out and back out the changes, and let them be committed again later, only when they are complete (the original committer having proven that they aren't interested in completing the project in a timely fashion, and the project proving that it's unwilling to tolerate sustained brokeneness). -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message