James Carlson wrote: > So, if as you're asserting that only the consolidations may have > releases, then exactly what do we tell customers and how do they know > what they're getting when they download bits?
Each consolidation has its own way of marking its reease value. ON uses uname, java uses 'java --version', JDS/Gnome use "help about", etc. In general, we have general mechanism whereby one can iterate thru a list of components and query their version; neither do we have one for expressing the version of a given product. The /etc/issue and /etc/releasename files are/were used by Solaris, and the Product Registry tries to define a framework for unbundleds, and the package database has some poor support for it. > Do we list each > consolidation's release binding or number on a web site somewhere? Why would this matter to the ARC? 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. Same for the NetBeans IDE, Java, JES, Identity management, SunGrid, Belenix, Schillix and the other distros... > How does the customer know which consolidations' products he's using? By using each consolidation's "tell me your version" interface as above? > > I think what you're saying is that not only are numbers like "Solaris > 10" purely marketing (and thus PAC) constructs, but that we no longer Yes - they always have been. Go back thru the ARC Chairs minutes from the last decade or so and you will find many discussions about how inadvisable it was to tie marketing names tightly to release taxonomy values... > 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... > Given that /usr/bin isn't special in Solaris and that > any consolidation can deliver there, some now (apparently) with > radically different release levels, how does any customer determine > what he's getting in the box? They rely on the fact that the product they are installing delivers a self-consistent set of components. Each of those components evolves at its own rate, subject to any integration measures that the P-Team chose to include. 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. > Does this new scheme apply only for [Open]Solaris, or is it for all This isn't a new scheme - it is the way things have always been since we deployed the SDF in the early '90s. Much of the confusion that has been created since then has been caused by people incorrectly expecting that the whole Solaris world must be treated as if it was the ON consolidation. Thru such misguided assumptions, the PAC's request to "put iAS into Solaris" became "we must stuff it into ON because ON is the WOS and that is the only way we know how to do it". 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. > products under review in the ARC? When we see a hardware product, > should we assume different release bindings for the hardware itself > and the firmware? Are they part of the same component? Does it make sense to release either of them independently of the other? If they are seperable, then yes, they are independent consolidations, each with (potentially) a different release binding. > > Do customers ever update just ON on their systems? I suspect that Probably not, but they get ON as part of many different products/distros. > excising or redefining the role of "Product" in our system will have > effects that we haven't anticipated. For one, it seems to make this > document unusable: > > http://www.opensolaris.org/os/community/arc/policies/release-taxonomy/ As I said to GaryW, when GaryS wrote this document, he was generalizing from the fact that, conceptually, a product can be made up of one or more consolidations, and, at that point, SunOS was effectively a single consolidation. It wasn't until SunView morphed into a non-kernel resident News/XNews/X server+libs and we broke off the compilers that Solaris became a multi-consolidation product (though it always was a wad of stuff) - but by then the document had already been written. I'm not sure what your concerns are - the ARCs have never controlled products; their impact has always been on the evolution of components and the projects that drive that evolution. 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). > (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: > PSARC 1995/191 DLM Memory Allocator for Oracle on Energizer > (19950706_greg.slaughter) > PSARC 1995/424 SunSoft/Oracle "One-Buttton-Installation" for project > BandWagon (19951207_steven.uhlir) > LSARC 1996/467 Single Sign On-Oracle > (19961221_teodora.ngo) > ASARC 1997/004 Solstice Backup Database Module for Oracle v2.0 > (19970107_elizabeth.bermudez) > ASARC 1998/009 Solstice Backup Database Module for Oracle, 2.1 > (19980109_gregory.schlabs) > PSARC 1999/229 Oracle Edition > (19990302_theresa.garcia) > PSARC 2002/308 Enterprise DHCP Oracle Module > (20020528_tobin.coziahr) > LSARC 2005/088 Oracle RDBMS 9i and 10g N1SPS Plugins 1.0 > (20050211_ted.persky) > WSARC 2007/159 Oracle 10g support for JES registry > (20070318_paul.sterk) -John
