Date: Thu, 5 Sep 1996 13:57:25 -0700 (MST) From: Terry Lambert <terry@lambert.org> To: p.richards@elsevier.co.uk (Paul Richards) Cc: rkw@dataplex.net, p.richards@elsevier.co.uk, current@FreeBSD.org Subject: Re: Latest Current build failure Message-ID: <199609052057.NAA09868@phaeton.artisoft.com> In-Reply-To: <573f0xx9uo.fsf@elsevier.co.uk> from "Paul Richards" at Sep 5, 96 04:25:19 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> Umm, well can we start this thread again on a more technical basis. > > A good place to start would be to list the current shortcomings that > people have with the current build system, work out a new design that > solves them and finally come up with a solution that can be > incrementally implemented so as not to make the system unusable at any > stage. Some current shortcomings of the existing system: 1) The "code vetting" model it does not scale adequately. This is a barrier to progress. 2) The requirement that systems be incrementally implemented forces the use of evolutionary rather than revolutionary approaches. This is a barrier to progress. 3) There is an inherent sociological and territorial limit to the concept of "management by core team". The principle behind this limit is inherent to all human endeavor. Linux is currentlly reaching their own limit in this regard; it just happens to be larger because the social construct "monarchy" has a higher sociological scalability index than the socialogical construct "feudal state" (aka "core team"). Expending of energy to fight this limit detracts from applying the same energy to increase forward motion. This is a barrier to progress. Richard wants to implement a revolutionary, not evolutionary, soloution to the problem domain "the build process". He is meeting with barrier #2, which is the same barrier I met with when I wanted to implement a revolutionary soloution to the problem domain "advanced file system design". There are similar examples for other problem domains, involving other participants, some of them core team members fighting their own #2 barriers. This ignores examples of #1 and #3 barrier conflict. This is intentional editing; examples are readily available. There are also more complex barries than the tree shown; however, if these three can not be recognized, then it is unlikely that the more abstract organizational barriers could be recognized either, so it is not fruitful to pursue them at this time. > Each stage can then be prototyped and incorporated without requiring > the all singing-all dancing implementation to be prototyped from > scratch and all in one go. People may get a better idea of the purpose > of the changes if they're done in stages, phased development is > generally the best way I find to move people towards a goal that they > don't appreciate from the outset. The old saw: how do you sanely implement revoloution? The US has a complete governmental overthrow every 4-8 years, and does so without blood running in the streets. All we are discussing here is a change in the rules of order -- we don't even want an overthrow. Yes, it's possible to take the OpenBSD approach -- hold our own "Constitutional Convention" and start down the same path which led FreeBSD to where it is today -- core-bound, as progress, as well as chaos, is turned back at the bulwarks. This has hardly been proven to be effective (yet -- OpenBSD may surprise us, even if the general model computes an answer that says it probably won't). Where are the API's one calls from within the system to change the system? Is a "Constitutional Convention" the only possible answer to the question of "how do we achieve large scale progress?" or the question of "how do we change the system?"? Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199609052057.NAA09868>