> I'm wondering, what thought has anyone seriously > given to the notion of > "shrinking" ON? > > It seems like anytime anyone has anything to putback > that doesn't fall > into SFW, JDS, or X11, they stick it into ON. > > This might not be such a terrible idea, except that > ON has gotten > really, really big. I have *got* to believe that the > amount of time > wasted by engineers waiting for simple things like > bringover, putback, > and file copies is significant, particularly taken > cumulatively. > > And, it seems like a *lot* of ON doesn't have any > natural reason to be > in ON, other than historical reason, or lack of any > better place to put > it. For example, the recent filebench integration. > Or perl 5.6.1. Or > endmail. Or pretty much the entire printing > subsystem. Or even the > libucb compatibility stuff. I'm sure there's a lot > more that could > easily be pared down. > > My point is, maybe we should consider a separate > consolidation, > "utility" or somesuch, for portions of ON that are > not actually required > to build or boot ON. I'd hazard a guess that this > would help out most > folks who work in ON a great deal -- regardless of > whether their project > was in ON or the new consolidation. (I mean come on, > do the folks > working on "vi" really need or a want a copy of the > entire kernel and > all the drivers? Or even a copy of libc?) > > I wouldn't be surprised to learn that X11 or JDS or > SFW have similar > concerns. Unbounded growth of consolidations is > probably painful > everywhere. Granted, someday hopefully we'll get > better tools (hg), but > even then, you have to populate an initial tree to > start working, so a > smaller consolidation is still beneficial.
How about an additional criteria for what's eligible to be moved out: no consolidation private interfaces used, nor any project private ones unless the whole "project" is moved out? That way, there aren't a bunch of new contracts needed, nor increased risks of out-of-sync changes. This message posted from opensolaris.org _______________________________________________ opensolaris-code mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/opensolaris-code
