Nicolas Williams wrote:
> And I don't see how that affects the discussion of this case, or zoo, or
> unzoo, or unison, or whatever -- unless the ARC has that under its
> charter and it just so happens that in most cases the question of
> meta-clusters will get the given software is ignored because... the ARC
> expects the c-team to do the right thing(?).
>
> The ARC mostly does not look at package meta-clusters. When I did the
> SQLite3 integration the cluster issue (i.e., what kind of installs get
> what packages) came up only at c-team review time[*].
>
> If the ARC needs to know what pkg cluster some FOSS ends up in, then let
> the ARC ask for that information, else why is that coming up now?
>
>> After all, if we know that there will be the 3 classes we referred to
>> earlier, (core, layered, wild west) then we can classify each FOSS case
>
> We can already do {core, layered, wild west} because we already have the
> tools for that: interface taxonomy (and per-consolidation/product
> integration rules, I suppose).
>
The problem with that idea is that the repository level and interface
taxonomy are not equivalent. In fact, they may be orthogonal.
The point being that this idea of core/layered/experimental has to do
with support and integration and little to do with stability. Anything
that was in this core would be expected to follow all of our
traditional rules for integration into ON. I would expect the ARC to
require following all the Big Rules and to examine the project for
following best practices. The project should leverage Solaris features
wherever feasible, although compatibility with other distros might be
given more weight than it is now. These would have full 7x24 support
available and the ability to escalate to get bugs fixed.
The layered things would still need to follow all of the Big Rules
(examining the Big Rules in this light leads one to believe that
perhaps some of the Big Rules should really just be "rules") and would
be expected to not ever break anything in the core. It might be
reasonable to allow incompatibilities between some of these packages
and others in this same repository. Or maybe not. What level of
support would be available is TBD.
The wild west is all bets are off, except it may be a requirement that
nothing break anything in core. Or maybe not.
The architectural rules are different in each case. But since the
current rules are the same as for core, if the argument is that the
endless discussion over each case is making the process to slow, then
that is proof of the need for the new rules to be documented and
reviewed. Then we can do useful architectural reviews without wasting
time on trying to determine what rules to apply for each case.
--
blu
There are two rules in life:
Rule 1- Don't tell people everything you know
----------------------------------------------------------------------
Brian Utterback - Solaris RPE, Sun Microsystems, Inc.
Ph:877-259-7345, Em:brian.utterback-at-ess-you-enn-dot-kom
