Jim Grisanzio writes:
> No need for SIGs since they are really just Communities. No need for
> Consolidations since that's a Sun term, and we should just keep making
I just know I'm going to regret poking my nose in here, but ...
How exactly is "Consolidation" only a Sun term? Regardless of the
name used, the concept reflects something that has substance and
meaning quite apart from any Sun internal documentation.
It's a collection of software that's intentionally built and delivered
as one unit and managed in a consistent way. It has one versioning
train and release vehicle. In architectural terms, it provides a
boundary within which cooperating projects are versioned in lock-step
and thus can freely share what would otherwise be unusable interfaces
and dependencies.
In the same way that a "User Group" is not well-represented as a
"Project," a consolidation is also not reasonably a Project. It
imposes integration- and release-related restrictions on other
Projects -- much in the way that a distributor might; and often as a
_proxy_ for the distributors ("please don't forget i18n"). It also
sometimes behaves as a community in shepherding related projects and
arbitrating among them.
It certainly would be possible to construct OpenSolaris solely of
independent Projects, and abolish forever the "consolidation" idea.
It would be a poorer and harsher environment -- many Projects would be
forced[1] (for the sake of compatibility with others) to nail down
interfaces that would otherwise be more fluid Consolidation Private
bits -- but it could be made to work. (Yes, I know full well that
this sort of stability would also have an upside; it's not necessary
to follow that tangent.)
This is, though, a key _technical_ choice for the community: do we
want to have a forest of independently versioned and maintained
projects, each with its own set of standards and plans, and each of
which delivering directly to distributors that are picking and
choosing bits, or do we want to have a smallish number of
consolidations into which projects integrate, and that act to set
standards?
I don't think I can answer that question. I know which one I prefer,
and I strongly suspect that others here prefer the other one. But we
_must_ choose explicitly among these important technical and strategic
options. Pretending that the issues don't exist or aren't relevant
won't make them go away.
1. I know someone will ask this: "who will force this?" The right
answer is that Mother Nature herself does the job if we refuse or
neglect to do it. If those formerly Consolidation Private
interfaces aren't treated as Committed when consolidations are
gone, then the result (by definition) must be incompatibility over
time as separate objects are versioned. When you change "foo" to
"bar," the other projects that are still calling "foo" will simply
break -- forcing them to change as well or forcing others to
refuse your change.
--
James Carlson, Solaris Networking <james.d.carlson at sun.com>
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
