John Plocher writes: > Nils Goroll wrote: > > And how is the problem of > > inter-consolidation dependencies solved for Solaris? > > One of the key activities we use to manage this is the ARC process, > specifically its interface taxonomy and focus on only allowing > components to consume Committed interfaces from others. If you disallow > dependencies on private or uncommitted interfaces, then you have a > problem that devolves into a simple change management exercise: > If you create a Committed interface for others to use, you can not > change it incompatibly without forcing a "Major Release" of your > component. The correlation is that consumers can depend on things > *not* breaking in "Minor", "Micro" or "Patch" releases.
An interesting wrinkle in this is that there's a difference between the required tools and bits used to _build_ the software, and the required bits to _run_ the software. The latter relies on the architectural rules and review process that you're describing, but the former doesn't necessarily. It's actually left to consolidations to manage. There are cases where the two are the same. For example, the Install consolidation depends on private interfaces from the ON consolidation that it uses under an ARC contract. These are delivered as special packages (SUNWzoneint, SUNWwbint) that aren't present in the WOS (a Solaris install DVD doesn't have them), but they have to be installed on any machine used as an Install build server (or you have to set special environment variables to find them elsewhere). In that case, the ARC issue and the build server issue are the same thing. In other cases, that's not true. For example, the fact that we now need SS12 to build ON isn't subject to ARC review. That's a gate management issue, but it affects those who have build machines just as much as one of those architectural dependencies. So, yes, Sun (and now everyone participating in OpenSolaris) does try hard to document and manage architectural dependencies, but those aren't the final word in the build server issues that started this thread. -- 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 opensolaris-code@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/opensolaris-code
