From owner-freebsd-arch Tue Jun 4 16:10:14 2002 Delivered-To: freebsd-arch@freebsd.org Received: from gull.mail.pas.earthlink.net (gull.mail.pas.earthlink.net [207.217.120.84]) by hub.freebsd.org (Postfix) with ESMTP id CC48937B404 for ; Tue, 4 Jun 2002 16:10:01 -0700 (PDT) Received: from pool0092.cvx40-bradley.dialup.earthlink.net ([216.244.42.92] helo=mindspring.com) by gull.prod.itd.earthlink.net with esmtp (Exim 3.33 #2) id 17FNR0-0004v2-00; Tue, 04 Jun 2002 16:09:51 -0700 Message-ID: <3CFD489C.D45F2ADE@mindspring.com> Date: Tue, 04 Jun 2002 16:09:16 -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: Bakul Shah Cc: Will Andrews , Kris Kennaway , arch@FreeBSD.ORG Subject: Re: Avoiding unnecessary breakage (was Re: Removing wait union) References: <200206041752.NAA08182@rodney.cnchost.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 Bakul Shah wrote: > Another possibility is to figure out a way to not cause so > much bit rot in the first place. Let me explain. [ ... ] > So there is usually a group (or an individual) commited > maintaining compatibility. Breaking interfaces is not prohibited > but it is not taken lightly. [ ... ] I think that I can safely characterize this as my "option #3", where the changes are vetted by "vetting committee"/Kris/software. I think this instantaneously creates a bottleneck. The emergent properties of this bottleneck are undesirable, even if the intent, to avoid breakage, is desirable. > Leaving such decisions solely upto developers doesn't work > because developers have their own agenda (which is frequently > at cross purposes with each others', and with the groups' > goals). I think Kris would probably agree with this. 8-). I do. > In my view having an active architecture group that is > responsibile for user/system interfaces would help > tremendously. In order for it to be effective it needs > people who have developers' respect for their judgement, > experience and technical skills. They need to be persuasive > and tough enough to help convince developers to work toward a > common goal. I'd agree with an architecture group, but I think the powers you want to grant are perhaps to far-reaching. Already, the mere existance of a tiered structure of core team, committers, the unwashed masses, is externally seen as being non-egalitarian in the extreme. There are also some intrinsic properties of such a system. The political analogs are super powers, the members of the "nuclear club", the unwashed masses; the economic analogy is first world nations (the G-8), second world nations, and the unwashed masses. The business version is executives. middle manage, the unwashed masses. The overriding intrisic property is that such systems are tier exclusionary, and they are self-perpetuating. Adding another tier of management is probably not the answer ("Welcome to the Star Chamber"). > Another mechanism idea to add to your list (I think > someone may have already mentioned it): > > - create an index of which ports use what include files, > what system/library calls etc. If an interface needs to be > changed the developer can quickly find out what ports will > be affected. If the developer were forced to fix these > ports before allowed to commit an interface change, most > people will think harder about changes! Actually, that was me that already mentioned this one; it was in the context of the "making BSD make into GNU make" thread. This is antithetical to the use of "automake/autoconf/configure" used by many ports. It's much closer to the "imake/xmkmf" way of abstracting system differences as a list of manifest constants. It's not that this approach won't work, it's that responsibility for compliance is pushed off onto the third party code maintainers; you are effectively telling them not to use certain tools that work perfectly fine for them on their single OS environment, and which help in making ports of their code -- at the expense of making the code itself less portable. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message