Devon H. O'Dell writes: > > I'm wondering, what thought has anyone seriously > > given to the notion of > > "shrinking" ON? > > One advantage to having a large what-is-referred-to-as-ON-in-OpenSolaris > `consolidation' is that, when built, you receive a system containing pretty > much everything you need as a user to get going. The BSDs have a similar > thing going -- there's sendmail (or postfix for NetBSD, I think) and BIND, > OpenSSL, all the standard command-line utilities (ls, grep, cut, sed, awk, > and what-have-you), the kernel, manpages for everything, and some other stuff > that I'm leaving out to be at least somewhat brief. It's possible (due to the > directory hierarchy and build infrastructure) to check out only specific bits > of what you're interested in, and there is some idea of consolidation in > building as well (one can disable building of BIND/sendmail/crypto libs, > build only the kernel, build only one utility).
There are two subtly different issues here. One is the form and structure of the source code management system and the other is the maintenance (gatekeeping) of that code. It'd be entirely possible to use something like the Mercurial 'forest' extension to treat each consolidation as a separate 'tree' within a single large source repository. Then you'd be able to "check out" just the part or parts you want (where "parts" are consolidations), and update them as you see fit, while still having a global view of the whole source base. That's distinct, though, from the nature of a consolidation. A consolidation is maintained as one set of software: a single set of build rules, a single delivery schedule, a common set of gatekeepers, and one set of style and process rules. The idea of having a smaller ON is having more trees in the forest, more distinct small bits that can be managed separately, and not just to make it difficult to find the source. > Well, I certainly don't know a whole lot of the rather large history behind > ON, what it was historically. I'll second Keith's comment on people working > on vi needing / wanting libc. I don't know how this is set up internally in > Sun, but I'd imagine someone working on vi is not limited to working > specifically on vi (and if so, I can't imagine them needing to work on it for > a period more than a couple months at the most). People who work in userland > utilities (in my experience) end up working in several of them. While they > may not *need* a copy of the kernel, openssl, sendmail, or perl for what > they're doing, having an environment that, when built, represents the entire, > hosted base of what they're working on is (in my view) more of a good thing > than not. Right; having multiple closely-related bits together does make sense. On the other hand, the chance that someone modifying vi really needs to modify libc as well seems vanishingly small to me. Shouldn't vi be sticking to the standardized interfaces and _not_ be sharing private tidbits with libc? I see no problem with making it easy to get "all" of the source and making sure that people working on vi (for instance) can immediately look at and enjoy the libc code, but that doesn't necessarily mean that vi and libc need to be (or should be) managed as a single unit of code. -- James Carlson, Solaris Networking <[EMAIL PROTECTED]> Sun Microsystems / 35 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 _______________________________________________ opensolaris-code mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/opensolaris-code
