Draft opinion (PSARC 2005/695)

[James Carlson]

John Plocher writes:
> 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

That's easy.  The discussion morphed because the text specifying the
release binding morphed.

I have no problem with identifying the consolidation (or list of
consolidations) into which a given project is integrating.  That's
obviously key for interpreting the 'private' interfaces and the
contracts.

I have a big problem with specifying the release binding as attaching
to a particular consolidation.  That isn't supported by the release
taxonomy, and clearly isn't supported by any ARC practice up through
November of last year.  Furthermore, the system itself cannot support
this sort of release binding, as the user documentation and visible
release information does *NOT* indicate what has been done.

> Each Distro has a set of goals - The Solaris distro chose extreme
> interface stability over time for its core.  This means that, when

No disagreement with that.  However, we still have a requirement that
we must be able to make those release bindings usable to those who
need to use them.  Otherwise, the whole exercise is pointless.

The distributors can, of course, ignore what we produce.  That's what
distributions have in front of them.  They can pick content.  We are
constrained, though, in that we have to produce usable information.

If what you're saying is that "a Minor release of Solaris" excludes
other distributions, you're quite right.  That doesn't mean that we
toss release vehicles out the window and use consolidations instead.
Instead, it means that we need to get other distributions involved
with the process -- so that we can bind to whatever they need as well.

I think what you're proposing is that consolidations have release
bindings, and that distributors can pick and choose among them without
necessarily declaring anything for their releases.  At least for
Solaris, I categorically reject that notion.  If Solaris has Major
changes in it, then it needs to be a Major release -- period.  We
cannot fudge on that or, quite frankly, nobody's going to believe our
compatibility story.  (And, again, that leads directly to a lack of
any real need for ARC review, because we've given up.)

> 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

That's untrue.  You do care, and you have to.  "Patch xxx" is
different from "Minor release yyy" in terms of risk, planning,
qualification testing, and third-party product support.

If there are "Major" changes in it, then you need to prepare for major
change, and you shouldn't adopt it lightly.  How can it be otherwise?

> 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)

That tells you exactly nothing if you cannot determine what the
releases are.  If the release information is buried in each
consolidation rather than on the outside of the tin, then you simply
cannot tell at all what you're getting, and our carefully-crafted man
page documentation isn't worth spit.

The man page for something Committed is saying (effectively) "won't
change until the next Major release."  Great.  What if Major releases
occur every week, because that's how the consolidation rolls?

That's an invitation to chaos.

> 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.

Release binding is relevant for interpreting stability.  Consolidation
*becomes* relevant when that's where you bind the release, which is
what was done in the last (undiscussed? unreviewed?) change to the
opinion template.  Bind it elsewhere, and it once again becomes
irrelevant.

> 	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,

"And, dear user, there's no real way to tell which bits are in which
bucket, so good luck with all that."

-- 
James Carlson, Solaris Networking              <james.d.carlson at sun.com>
Sun Microsystems / 1 Network Drive         71.232W   Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757   42.496N   Fax +1 781 442 1677