Mainly, it as to do with availability of
libraries/headers on Solaris
This might be a good time to kick off an "ARC-like" discussion of how
sharable things - such as reusable FOSS components - *should* be structured
to allow for maximal reuse at minimal effort and risk.
It is also a good time to try and model Sun's architectural development
process so that the OpenSolaris community can understand it, can
successfully interact with it, and can ultimately join and participate
in it.
I've Cc'd the discussion to the opensolaris-arc alias and directed
follow ups there.
Check out <http://blogs.sun.com/plocher> for more information on Sun's
Architecture and Development processes.
Some Architectural background:
The Architecture Review Committees (ARCs) are responsible for the
architecture
process at Sun. The "Systems Architecture" effort at Sun is a process that
establishes the basis for multiple engineering projects to be developed in
parallel and then to integrate with each other and the existing system,
either
at Sun or in the customer's hands.
Sun's Architecture Review Committees (ARCs) review and approve technical
aspects of software projects, implementing a process to manage technical
change in the architecture of our software systems. These architectural
reviews:
* assure that a technical description of the project exists,
* assure the developers' plans are technically sound and consistent with
current conventions and existing products,
* collect and archive project specifications, and
* improve inter-project coordination: decrease the likelihood that projects
conflict with (or duplicate) each other.
The goal of the ARC process is to consistently fulfill our customers'
expectations of what a Sun product is, across the product line and over
generations of products
Reusable software:
One of the recurring problems that we try to manage at Sun is how to
effectively reuse components that should be reusable.
Reused components add risk to complex systems, primarily because
incompatible changes to a component will break other parts of the
system.
The FOSS/distro world many times deals with this situation by resyncing
and recompiling whole subsystems every time some component revs in an
incompatible way, giving what I call "source level compatibility".
Think gentoo and autoconf.
An alternative chosen by Sun is to provide "binary compatibility", even
in the face of incompatible change. This requires that we worry a lot
more about changes to the interfaces between components:
o Exposing too many implementation details makes it difficult to evolve
a component without breaking things that depend on it. We call
exposed interfaces "public" and implementation details "private".
o Interfaces have expectations that need to be set and managed. We ask
"Can we expect this interface to be stable over releases, or is it
more of an experimental thing that will change in the next release?
o As a component evolves, we ask "what interfaces have you changed, and
what expectations did you set when you first exposed them?
o We use two taxonomies to help us keep track of all this - an
interface taxonomy that sets expectations of stability and a release
taxonomy that defines the type of release that can contain the
changed interface.
Stability: Public: Stable, Unstable, Volatile, "not an interface"
Private: Consolidation Private, Project Private
Releases: Major, Minor, Micro, Patch
There is a relationship between the two:
Incompatible changes to a XXX interface are only allowed to be made
in a YYY release of the consolidation that contains that interface.
XXX YYY
--- ---
Stable Major
Unstable Major or Minor
Volatile Major or Minor or Micro
NAI any time
* Private any time
What does this mean for the Companion CD?
As long as the components that are part of the Companion CD are not
reused by anything else in OpenSolaris, it is easy to "not care" about
how they evolve or change. The collection (which we call a
"consolidation") would be both low-risk and low-maintenance.
As these components start to get reused as building blocks for other
parts of the system, the potential cost to the system increases. If a
component changes in an incompatible way, all the things that depend on
it will need to react; if they don't, things may/will break.
A project to revamp the companion CD will need to address these issues
in some way; the fun (and follow ups) will be in figuring out what is the
best way - for both a "companion CD replacement" *AND* for the OpenSolaris
systems that will reuse it.
-John Plocher
Staff Engineer, Architecture and Development Processes
Sun Microsystems, Menlo Park, CA
_______________________________________________
opensolaris-discuss mailing list
[email protected]
