James Carlson wrote:
> 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?
Right now, they can either use the Product Registry or grovel thru
/var/sadm/install/contents. Or, better, they could read the release
notes and other product literature that came with the product they
acquired to see what was in it.
How is this an architectural issue and not a product marketing/customer
satisfaction issue?
>
>>> 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.
I somewhat disagree - the ARC isn't directly responsible for those
product-specific details, the distro team (PAC, P-Team...) is.
I don't disagree that it is important that the ARC make sure that
various interfaces(etc) in a consolidation are sufficiently documented
(interface taxonomy and all that) and that the release binding of the
various proposals is clearly articulated. It is also part of the
(delegated) scope of the ARC to ensure that this release binding info
is used appropriately by the gatekeepers for each of the various
consolidation instances, so that projects only integrate into the
places that they were approved for.
> 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.
???
The ARCs control the evolution of consolidations. This is the same
read-write-iterate SDF/ARC process we have been using for the last
17+ years at Sun.
Someone (Was the PACs, now is some mix of OS.O communities and the OGB)
controls what new consolidation instances are chartered and what their
release taxonomy bindings will be.
Distro teams build their castles by controling the selection and
integration of specific versioned consolidation instances.
Where do you see "write-only" memory here?
> The missing part is how any customer or third party vendor who gets
> that composite "product" knows what the heck the product *is*.
Look on the "ingredients list" on the product box? Maybe there
is a hole here in that the ARCs have not pushed for the development
of a way to iterate thru the list of included consolidations, or
that there is no uniform way to query a consolidation for its version
information, but I don't see how changing the wording of an ARC Opinion
to better reflect its intent affects this problem at all...
> - 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.
I've not seen anything from the other distros that would lead me to
presume that their version numbers mean anything more than a way
to disambiguate their sequential release stream...
>
> - 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.
Just like SX and the bi-weekly OS.o ON releases...
>
>>> 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.
Again, how does changing the wording in the opinion template a this?
> I still don't see where the implications of that change were discussed
> with the rest of the ARC.
This is/was a recurring conversation at ARC Chairs; it also was brought
up as part of the ARC-Next effort and a reaction to complaints from the
ON Cteam. As a clerical cleanup to make the opinion match the SDF
and the way that we do business, it didn't need more than a mention in
an ARC Chairs meeting.
> And, yet, we (in the ARC) have been binding things to Solaris releases
> for years and years.
... and engendering confusion throughout the company every time.
Projects don't integrate into products - they integrate into
consolidations. C-Teams and Gatekeepers consume these opinions to
determine which putbacks they can allow, based on their ARC approval
and binding.
> I don't believe we can or should actually do that until users can
> identify consolidations.
Sounds OK to me - go start such a project. They can't do so today,
yet the world still goes 'round...
> 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.
The key consumer of consolidation release bindings is the Distro team
that is building a product, NOT the customer who uses that product.
If the product is intended to be "Stable", the distro team needs to
ensure that the components it uses to build it are also "Stable". That
probably means that they need to eschew major releases of their core
components and create compatibility glue (like the java stuff) in places
where they can't do so.
If nothing else, this discussion shows how intertwined PSARC is in
the multiple roles of ON-ARC, Distro-agnostic-ARC and Solaris-WOS-ARC,
not to mention Platform-ARC...
-John
