On Wed, Apr 16, 2008 at 09:18:10AM -0400, Brian Utterback wrote:
> >>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
Support model is a business issue. Interface stability is an ARC issue.
I repeat: the ARC does not usually care what meta-cluster anything it
reviews ends up in. Has the ARC been ignoring its responsibility to do
so? Or did it never have that responsibility?
If the answers are "no" and "it never had that responsibility" then the
whole Indiana repository thing is orthogonal to the ARC unless we change
the rules.
(Which isn't to say that the ARC doesn't get to look at architecture
issues w.r.t. packaging architecture, repository access methods, etc...)
I don't see how the repository idea changes much of anything for the
ARC, EXCEPT that it might, or perhaps should, make i-teams and the ARC
more willing to go with Volatile (and Obsolete Volatile) for "wild west"
type software (FOSS or otherwise) interfaces, and the ARC and the
c-teams more willing to waive Big Rules with little discussion (see
below).
> 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 ARC and c-teams already waive some Big Rule requirements for FOSS
(e.g., L10N -- much FOSS doesn't do L10N).
I think we could formalize a notion of core/layered vs. "wild west" that
makes the waivers closer to automatic. But I don't see that as a
significant change from where we stand -- it'd be a convention built on
the existing rules.
> 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
Whereas I think they are the same, with exemptions granted near
automatically for some things.
> 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
Endless discussion is an issue. Establishing a core/layered vs. "wild
west" convention would make much of that go away.
Nico
--
