2008/344 [ksh93 Integration Update 1 Amendments 1]

[John Beck]

This has gotten way off the track of architectural review, so I have moved
psarc-ext to the blind copy list.


Garrett> ... Solaris integrations always need to conform to a "release ready"
Garrett> rule.  That is, we don't integrate software that aren't comfortable
Garrett> including in a full release, as that software exists *at the time of
Garrett> integration*.

Alan> I don't believe that's the actual rule - I know the ON consolidation has
Alan> that as a rough goal, but integrations of beta versions are explicitly
Alan> allowed in other consolidations, and I'm not sure where the ON rule
Alan> banning it would be written down.

Roland> AFAIK the gatekeeper (John Beck) has the final authority on that,
Roland> right ?

No, I am the ON C-team tech lead, not the gatekeeper, the difference being
that the gatekeeper enforces the rules (think a state's attorney general)
whereas the tech lead helps set the rules (think a governor).  And as Alan
noted there are different consolidations (the "C" in C-team) that make up
the WOS, and this issue is one where different "states" have different rules
rather than there being a single overriding "federal" rule.

In ON's case, we have a fair amount of software that we get from outside
(sendmail, Perl, BIND) and we generally only revise those modules in a way
that corresponds to release boundaries of the external module.  I.e., I
never putback sendmail Alpha or Beta versions, only "final" versions.  My
experience is that Perl, BIND et al. have been dealt with in the same manner
though I could not swear that has been true for every external module for
the entire history of ON.

In this case, we (the ON C-team) would want to know how stable the module
in question is, what would be gained or lost by taking it now as opposed to
waiting until a "released" version, etc.  Then we would make a judgement call
once we had all the facts in front of us.

Meanwhile, can we please stop diving into rat-holes and instead concentrate
on the high-level architecture?

-- John

http://blogs.sun.com/jbeck