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
