Draft opinion (PSARC 2005/695)

[John Plocher]

Brian Utterback wrote:
> So, as using your approach

I'm not sure how this discussion about making ARC Opinions state the
correct consolidation integration parameters ("a minor release of the
ON consolidation") has morphed into a diatribe about how hard it is for
end users to map artifacts back to consolidations or to enumerate the
list of Consolidations found in a specific product.  I absolutely agree
that it is hard; I'm also completely unconvinced that these problems
have anything to do with the wording of the Opinion.

This Opinion info is intended to be consumed by the developers of
the project, the consolidation and the distro(s) that include them;
it is not in itself an end-user deliverable, though there may be
reflections of the consolidation in the contents file, the product
registry, etc.  There may even be ways to extract the consolidation's
version info from a running system, but those mechanisms are
unfortunately mostly accidental and not very useful.  But, even if
they existed and were easy to obtain, they still would not provide
useful info to the end user.

Each Distro has a set of goals - The Solaris distro chose extreme
interface stability over time for its core.  This means that, when
the Solaris Distro Product team goes off and constructs the next
release of its product, it will tend to choose to construct it out
of the most recent Minor or Micro release of the ON consolidation.
Other Distros may make the same or different choices, depending on
their needs and what "kinds" of ON instances are available....

If you are a user of the Solaris Distro, you shouldn't have to
know or care about /how/ the release team built the product; your
questions about stability are answered by the Solaris' product's
policy to include such stability info on man pages.  Want to know
if "foo" is something you can depend on?, look it up with the man(1)
command.  Where it lives in the filesystem, what consolidation it
came out of, whethere it was written by Sun or Someone Else, what
language it was written in - all of these are irrelevant when it
comes to the interface stability question.

When you get the next version of Solaris, you /expect/ it to have
been constructed in such a way that its historical stability
expectations are honored.  It is up to the Solaris Distro producer
to inform you of anything that would change those expectations.
And, as long as the Distro keeps meeting those expectations, you
don't need to care about the details of how they did it.

It all boils down to product expectations:

	The Solaris Distro says that, for its Marketing releases,
	  The core of the system is Committed (see man(1)...)
	  The desktop follows the GNOME Foundation's lead;
	  some things are Committed, others track the community
	  Java evolves faster than the core, but we try to keep
	  the last couple of versions around to help you transition,

	The Nextenta Distro, on the other hand, seems to say
	  We follow the OS.o ON Community for the core,
	  We follow the cutting edge (unstable) of Debian,
	  and we do a bunch of work to try to make Solaris Distro
	  things "just work", but it all is a work in progress...

Certainly, Distro developers care about consolidations and their
release taxonomy; I'm unconvinced that end users or ISV developers
need to care.

    -John