Richard Lowe wrote:
John Plocher wrote:
Uname says SunOS 5.10. Marketing says Solaris10. Enginerds see a
connection
and jump to unwarranted conclusions :-)
As an aside,
most people seem to have reached that same conclusion, needlessly
deviating from it doesn't seem wise.
The problem isn't that ON's uname(SunOS 5.10) drives the marketing
name Solaris10, but that people assume that because ON is a Minor
release, all of the other consolidations that go into Solaris must
also be Minor releases, and that the mix of consolidations going
into Solaris can't change because it is a Minor release.
We see this in comments that elide the difference and say "a Minor
release of Solaris. While this is somewhat understandable coming from
ON developers whose whole world revolves around the core of Solaris),
it *is* an imprecise and confusing usage. Maybe I'm being too sensitive.
The more I think about it, the more messy having this kind of autonomy
at the consolidation level seems to become.
Historically, the PAC chose what kinds of consolidations[*] to charter.
Now the OpenSolaris Community Core members have that responsibility.
This is new ground for all of us (and sometimes it really scares me :-),
so discussions like this are important to make sure we don't screw things
up.
At the end of Solaris10's development, the Solaris PAC decided that it
wanted to devote resources towards delivering three new product lines:
Solaris Express - based on Solaris <next version>
Solaris10 UpdateX - based on Solaris10 with selected features
brought over from Solaris <next version>, and
Solaris <next version>
This required them to create two new releases of ON to go into those
new products:
ON10update1 - with a Patch Release Taxonomy level, and
ONnv - with a Minor Release Taxonomy level.
With the opening of Solaris, the Solaris PAC has changed its tune
slightly. Now they are working on:
Solaris Express - based directly on OpenSolaris ON
Solaris10 updateX - based on Solaris10 with selected
features brought over from OpenSolaris
Solaris <next version> - based on <this discussion?>
____
* In this context, a consolidation can be thought of as a source tree with
a gatekeeper and a set of program managers who are tasked to deliver a
version of the source tree that meets the set of requirements enumerated
in its charter. Sometimes the requirements are explicit lists of new
features (zfs, zones...) and sometimes it is quality (no P1 or P2 show
stoppers) or even date driven (release at the same time as the Niagara
processor based systems)
To take the hypothetical Major release further. JDS decides on a micro
release, SFW, X and Install decide on a minor release, on ON decides on
a major release. All niceties aside, what you're left with is unlikely
to be a product, but a mess.
I absolutely agree - such a situation would be a mess.
However, this doesn't change the fact that the community is still very
much in charge of its destiny, though it certainly is strong advice to
the community to not go down that Major release path.
-John
_______________________________________________
opensolaris-code mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/opensolaris-code
