John Plocher writes:
> ON uses uname, java uses 'java --version', JDS/Gnome use "help about",
> etc.
This skips over a fundamental question: how does any user know which
bit belongs with which consolidation in the WOS?
I don't see very many helpful bright lines here. Can you help me out?
> > Do we list each
> > consolidation's release binding or number on a web site somewhere?
>
> Why would this matter to the ARC?
I think it matters deeply, and that seems to be at the core of this
confusion.
One of the things the ARC must do is make sure that expectations are
*clearly* communicated to customers and those who build products atop
Sun products, such as Solaris. That's why we have written release and
interface taxonomies, and we clearly specify what sorts of
documentation and communication mechanisms are expected in support of
those designations.
If there is no such clear communication, then we're building castles
in the air. There's very little point to having an ARC at all if the
stability levels and other things we're working so hard to maintain
are written into write-only memory.
> I presume that the P-Team for
> a given Solaris-the-vinyl-binder product has a list of consolidations
> and associated versions that they will use to construct their product.
> The publication of that list to customers seems to be a product-specific
> action to be done by the P-Team as they react to their customer's demands.
I presume that, too.
The missing part is how any customer or third party vendor who gets
that composite "product" knows what the heck the product *is*.
> Same for the NetBeans IDE, Java, JES, Identity management, SunGrid,
> Belenix, Schillix and the other distros...
Sure. They do one of (at least) two things:
- Communicate to their respective customers how they're versioning
things and what those users can depend on. This could just be the
'largest' of the bindings among the consolidations.
- Throw in the towel. Each release is distinct and not a controlled
series. They're probably just stamped with a date code like a can
of peas. What's in it? Who cares? It's the Latest 'n' Greatest,
and that's all you need to know. Just don't try building on it.
> > How does the customer know which consolidations' products he's using?
>
> By using each consolidation's "tell me your version" interface as above?
There's no such interface. That's precisely the problem.
It does not exist in general, and for something that's suddenly so
important, we've put precious little effort into doing this.
I say "suddenly" here, because until your change to the template last
September (SCCS ID 1.21), the example text read like this:
The project may be delivered in a minor release of Solaris.
I still don't see where the implications of that change were discussed
with the rest of the ARC.
> > guarantee anything other than the contents of ON based on the output
> > of "uname -r."
>
> ... and we haven't done so for years and years.
> ON != WOS != Solaris-the-vinyl-binder...
And, yet, we (in the ARC) have been binding things to Solaris releases
for years and years. At least up until this past September, when that
rule changed.
> This is how we have been able to include new versions of Java, C,
> JES, JDS, etc in the Solaris product - even when they have major
> releases and ON doesn't.
For Java, we've intentionally caused them to ship multiple versions
and have a transition story, for *PRECISELY* this reason. If they
were just major releases without reference to any sort of Solaris
standards, then that wouldn't have been necessary.
For JES and JDS, I admit I don't really know what's going on or how it
lines up with previously well-known Solaris release standards. I do
know that we've had ongoing discussions about whether bundling in the
WOS is really the best answer, given expectations.
> This distinction is all the more germain now that we have many
> different products building on top of the ON consolidation - SX
> and SDX from Sun, and Belenix, Nextenta, Schillix, ... from outside
> of Sun - it should be clear that we are not talking about a product
> instance but instead a consolidation.
I don't believe we can or should actually do that until users can
identify consolidations.
Quick: what consolidations do /usr/sfw/sbin/tcpd and /usr/bin/zip
belong to? No fair looking at the source.
> I'm not sure what your concerns are - the ARCs have never controlled
> products;
Agreed. That's not what I'm asserting.
> their impact has always been on the evolution of components
> and the projects that drive that evolution.
Agreed, also.
> The construction of products
> out of the set of available released consolidation instances is one that
> is owned and driven by the distro-teams (aka P-teams and Release Engineering).
Still agreed. However, the communication of release bindings is a
*KEY* concern of architectural review. If that doesn't happen and (by
design) cannot happen, then we might as well pack it in now. We're
done here, because we're no longer building a product.
> > (And since when do we ship Oracle?!)
>
> It shipped in (at least) the S9 and S10 product boxes; I don't
> know about the update releases. Some of the reviews have even
> gone thru PSARC:
Surprise to me. Those are mostly support bits, not Oracle the
product.
> > PSARC 1999/229 Oracle Edition
> > (19990302_theresa.garcia)
"closed withdrawn"
--
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
