From owner-freebsd-current Tue May 9 1:58:34 2000 Delivered-To: freebsd-current@freebsd.org Received: from axl.ops.uunet.co.za (axl.ops.uunet.co.za [196.31.2.163]) by hub.freebsd.org (Postfix) with ESMTP id 137A837BD5F; Tue, 9 May 2000 01:58:24 -0700 (PDT) (envelope-from sheldonh@axl.ops.uunet.co.za) Received: from sheldonh (helo=axl.ops.uunet.co.za) by axl.ops.uunet.co.za with local-esmtp (Exim 3.13 #1) id 12p5q9-000JvY-00; Tue, 09 May 2000 10:58:05 +0200 From: Sheldon Hearn To: "Jeroen C. van Gelderen" , Bruce Evans , "David O'Brien" , current@FreeBSD.ORG Subject: Re: Small MAKEDEV bug In-reply-to: Your message of "Tue, 09 May 2000 10:26:05 +0200." <76232.957860765@axl.ops.uunet.co.za> Date: Tue, 09 May 2000 10:58:05 +0200 Message-ID: <76603.957862685@axl.ops.uunet.co.za> Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tue, 09 May 2000 10:26:05 +0200, Sheldon Hearn wrote: > I don't agree. I think this is an issue of avoiding changes that > unnecessarily astonish existing users. If you can find ways to improve > MAKEDEV that don't inconvenience those already familiar with it, great. > If your improvements astonish these people, you need to put a bit more > thought into what you're actually scoring. I'd like to follow up on myself with a comment that takes a slightly broader view on the problem. As FreeBSD's user base grows, we're going to see two different demands in increasing contention with each other. 1) The demand for an intuitive, consistent interface. 2) The demand for a constant interface. The former represents the need for POLA to be upheld throughout the system at a given moment in time. The latter represents the need for POLA to be upheld from one release to the next, in the arena of "backward compatibility". Both are valid issues that deserve careful thought. In many situations, we can fix inconsistencies "in the moment" without forcing folks to change the way they do things from on release to the next. In those situations where we have to make a decision one way or another, the decision is going to become more and more difficult as the project moves forward. I don't think that the only rule of thumb that can be applied where the two demands are in contention with one another, is that it's worth thinking carefully about what we gain for the change. But we can _certainly_ agree that it's always worth thinking carefully about ways to satisfy _both_ demands wherever possible. Ciao, Sheldon. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message