Date: Tue, 13 Jan 1998 22:08:26 +0000 (GMT) From: Terry Lambert <tlambert@primenet.com> To: eivind@yes.no (Eivind Eklund) Cc: tlambert@primenet.com, perhaps@yes.no, hackers@freebsd.org Subject: Re: X based Free installation Message-ID: <199801132208.PAA27653@usr02.primenet.com> In-Reply-To: <19980113023414.60851@follo.net> from "Eivind Eklund" at Jan 13, 98 02:34:14 am
next in thread | previous in thread | raw e-mail | index | archive | help
> > > There is only one organizational problem with FreeBSD that I see > > > clearly today: Responsibility too often boils down to a group of > > > people, instead of one person. I think each submission/contact to > > > FreeBSD should boil down to the responsibility of _one_ person. > > > > I'm not going to get into this right now; my opinions are known, > > and you can look them up in the archives. 8-). > > As far as I've been able to tell (from reading your posts before, and > looking them up again now): You want FreeBSD to have sexy tech, to > expand the treshold for the number of participants, and to throw out > the core team (with no clear indication of what is to replace it, if > anything.) > > All in all, handwaving, with no actual ways to solve any of the > problems, except that you claim to be able to supply some of the sexy > tech if people just didn't stand in your way. > > All of the above has been extracted from a myriad of complex > metaphors, so please correct me if I've misunderstood something. I told you I didn't want to get into this right now. But if you are going to call me publically, I'm going to respond publically. I don't want to throw out the core team members. Only the limiting aspects of the core team construct. If I were willing to "throw out the baby with the bathwater", I'd have started "TerryBSD" long ago, and not discouraged others from starting "JohnBSD" or "RichardBSD" or "DennisBSD" or "YourNameHereBSD". And I *have* _actively_ discouraged just such schisms. The core team construct also has its good points. There _is_ at least one baby in there that you would be throwing out. The limiting aspects of the construct include: o Opportunity for kingdom building, and the corresponding opportunity for wall trampling o Members being forced into increasingly demanding crises management roles o Inability to set unpopular policy that would benefit the project because of consensus, not majority, requirements for a decision o Inability to set concrete go/no-go deadlines, for many of the same reasons o Inability to rapidly integrate new technology, and not just mine; BSD4.4 was released for over a year before integration. SMP at the "big lock, bad scheduler" level was implemented by Jack Vogel almost two years before it made it onto a branch. o Inability to do top level design outside areas of the core teams expertise, resulting in hacks on hacks. Like NFS. o Many more. There is inherent conservatism in the social construct. I argue that conservatism is bad if one wants to promote revolution over evolution. We have seen where evolution ends: Microsoft kicks your butt, while your best assets slowly turn into liabilities (an NFS that doesn't work, networking where ISO, X.25, and other code has been made unusable by small scope, a stacking FS architecture that doesn't stack, critical tools no longer supported by their vendors, etc.). We have seen where the conservatism of USL (be the best by not allowing anyone else to advance the state of the art), SCO, Interactive, SunSoft, and other commercial UNIX vendors have gotten them: the top of a tiny niche. Like Apple, owner of 100% of 6% instead of 40% of 50%. I have suggested voting forums. I have suggested Lieutenants (hard to implement a fuedal system like Linux without a Linus for them to swear fealty to). I have suggested process for removing various aspects of crisis from need for management; the thread about buildability of the -current tree is only the most recent rehash of these. And yes, I've used analogies to do this instead of of obscure mathematics, which could provide "proof" to a much smaller audience that would be persuaded by analogies. As to "sexy tech" being hand waving... o Who gathered up and resolved the collision in the patches to 386BSD 0.1 so it would even run on many of the now-core-members systems? o Where do you think LKM's came from? o Were do you think the idea of an execution class loader (ABI compatability) came from? o Who wrote the SYSINIT code and rationalized init_main.c and the spawning of "kernel proceses"? o Who saved Jack Vogel's SMP code when his SMP box was "repossesed"? (Too bad his SPARC port wasn't saved as well...). And I've posted patches for many things that were not integrated due to the complexity of the vetting process: o NFS server side locking support (all but the rpc.lockd changes) o NFS client locking segregation support (you have to be able to back a lock out locally to be able to accept a remote rejection of the request, and you have to apply it locally so that you can reassert after a server reboot). o FS stacking cleanup o FS namei changes for Unicode and other alternat namespace support (VFAT/VFAT32/NTFS ring any bells?) o Etc. Go back and look at the -current archives. I've posted them all there. Feel free to check out an old source tree, integrate them, and then bring them up to date. God knows I've had to do it often enough. Then try to get them committed over the social inertia. > Now, I'm trying to come up with one pragmatic approach to how we can > increase the treshold for the number of participants without putting a > lot of non-existing resources at the problem. If the approach don't > work, the most likely outcome is that no people register to actually > write code - so the cost end up at 2 hours of my time. If it works, > we get more good changes for FreeBSD - great! More power to you. I kind of doubt that people buried in the throes of crises management will be able to dig themselves out to the point that they can participate in the process (see Jordan's comments; they are salient, and to the point, though he doesn't give the underlying problem as his rationale). Feel free to prove me wrong through example. > > > Does this mean that I'm the only person that belive this would be > > > useful? > > > > Probably. Ask yourself if a mentor program will increase the > > smallest harmonic wavelength of all harmonics that apply. Define > > the harmonics any way you want, or look in the archives for my > > definitions, and use them. Either way, I think a mentor program > > won't really help resolve the issues resulting in the limit function. > > Then try to come up with your definitions of the problems in words of > less than two levels of indirection. You can't have a meta-discussion without a "meta". Here's a concrete example, since you demanded one. Taking only the crises management aspects into account, I don't think David Greenman, Jordan Hubbard, or the many other people who are busy juggling cats, will be able to resonably participate as mentors (note the distinction between desire and fulfillment in that sentence). I think you will end up with many more "Billy Batsons" than "Mentors" if you pursue this. Please pursue it anyway; it will be a useful indicator of where the resource starvation is actually occurring. With a metric proving it, maybe something can be done about it. > If after four months the committers that have volunteered to be > mentors/contacts feel that the program have contributed more to > FreeBSD/will contribute more to FreeBSD than it has cost them, the > program shall be deemed successfull and shall not be discontinued. > > Very simple :-) Fine. Implement it. Apply the metric. Run the experiment so that we can get an emperical answer instead of hand-waving over our assumptions. Prove that your hypothesis is right and that mine is wrong. I'll even let you limit your demographics to only the people who believed it would work in the first place, as you have, even though it will be a biased measure of positive vs. negative impact of the program. Regards, 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?199801132208.PAA27653>