On Sun, Jan 27, 2008 at 02:13:33PM -0800, Ben Rockwood wrote: > In some senses the ON CG is the mother from which others flow. The idea > is that most OS projects are going to intersect with ON to some degree, > thus becoming projects of that CG. At some later point the grow > sufficiently to be "upgraded" to a CG. > > For example, if we ran the clock back, SMF or DTrace might have started > as ON Projects. As they grew and matured they would have reached a > point at which they needed to be upgraded to a full CG.
Ok, your thinking is where mine was a year ago (Consolidation-sponsoring Community Groups, anyone?). There are two problems with this approach that have become apparent in that time: 1. If consolidations are CGs, then virtually all the other CGs, including some that are actually functioning as well as might be hoped, have to go, and we have nothing with which to replace them. SMF is not a Project any longer, it's a SIG that is working with several Project Teams, each of which is targetting ON. I'm fine with destroying SMF as a CG as long as the value it actually represents is preserved with some other name and a charter that corresponds to the activities in which it's actually engaged. Managing a repository containing a piece of software called SMF and issuing occasional releases from it are not among those activities. 2. Community Groups are first-class citizens, but consolidations are not. Along the same lines as my reasoning in my earlier message, the Apache web server is a product, a first-class citizen. ON is not, and even if you think it is, Network Storage, to take a different example, most certainly is not. We're making an integrated technology base here, not a couple dozen standalone products. CGs map well onto standalone products, but if we assert that consolidations are CGs, there is no way to represent relationships among them: the ARC, the W-team, etc. OpenSolaris is a richer place than can be described in a simplistic three-level hierarchy. That each level can be enriched by internal constructs does not help, because we lack the ability to describe the real working relationships among these things with what we have now. > Dr. Fielding has spoken of this in the past at ASF, where they regularly > look for Sub-Projects that take on a life of their own and need to be > uplifted into full Project status. Yes. But this seems like evidence of the exact wrong idea (for us): that once a piece of software becomes large enough to "stand on its own", it should be split apart from its context of creation into some independently governed thing. This is the exact opposite of what we should be trying to accomplish: getting people to write better-integrated software that functions properly as part of a larger whole. Instead of creating a new CG, we should be creating another directory under usr/src/lib or usr/src/uts. That distinction matters because we want a maintainable gate, not because the new thing should stop being a part of the same product organised by the same institutions. > As to the comment regarding most CG's being SIG's today... I agree. We > have known for some time (see OGB/2007/002) that a lot of shuffling > needs to occur, and in many cases CG's just need to be destroyed. If a > CG isn't operating properly then its useless and needs to be removed, > with the hope that at some point it will come back to life with proper > organization and determination. > > But before we can go around smashing CG's and Projects we need to > address the current cultural misunderstanding in how the system is > supposed to work. Most of the friction that comes from any discussion > of removing a CG today is the result of a misunderstanding in their > function, organization, and implementation. Agreed. But we also need something sensible to replace them with. -- Keith M Wesolowski "Sir, we're surrounded!" Fishworks "Excellent; we can attack in any direction!"
