LSARC/2008/061 - Indiana check list

[James Carlson]

John Fischer writes:
> I am sponsoring this project for myself as a representative
> of the ARC community and a C-Team producing many Indiana projects
> in the near future.  The attached check list is also in the
> project directory.  I have set a time out for Tuesday, February
> 5th, 2008.

I suspect I'm missing some background necessary to review this, so if
you could indulge me some questions, I'd appreciate it.

I'm a little confused about the relationship between this checklist
and Indiana.  If this is just a "how do we deal with externally-run
open source" guideline, then it sounds good to have, but I'm not sure
why it needs to be focused on Indiana in particular.  It should be
generic goodness, right?

If an open source project plans to integrate into one of the existing
OpenSolaris consolidations, but the project team isn't one that's
working on Indiana, is the checklist unusable?  (How do we verify
that?)

One possible answer is that this checklist is an attempt to codify
rules about how projects integrate into Indiana.  But if that's the
case, it sounds to me like a non-sequitur, because Indiana is
currently (or last I understood _was_) just a project with alpha-test
bits.  It's not a release or a consolidation, as far as I understand,
so there's no ARC role to play.  If it is now one of those release
vehicles then (besides the OpenSolaris constitutional requirements,
which are probably out of scope here) shouldn't we at least have some
sort of release binding information?

How exactly do we evaluate dependencies and stability levels without
paying attention to release binding?

Comments on the text of the proposal:

>     line.  Each architecture review was conducted within Sun's control.  With
>     the advent of Free Open Source Software processes the control that Sun as
>     a company can wield has been diminished.  Now that Sun is moving to a more

Perhaps it doesn't matter much in terms of how the checklist will be
used, but I think that this discussion of "control" completely misses
the point.  Architectural review has always been about producing a
coherent system, and not about "control."

To be explicit: we do not actually need control over an external
software provider in order to produce a meaningful architectural
review.  In fact, having control has *never* been a requirement.

Instead, just like legal review, code review, laws of physics, and
other such matters, the existence or absence of project team control
over the contents of their delivery forms another constraint.  If the
ARC says "you must do X" in order to integrate, and if "X" is not
possible in your constrained universe and providing a cogent argument
that sways the ARC members otherwise doesn't work, then you cannot
integrate.  It's really as simple as that.

In other words, if a project team comes to the ARC and says (for
example) that they're going to depend on FooBar, but FooBar's
interfaces are all Volatile or Private, and FooBar is in another
consolidation, and the owner of FooBar refuses to provide a contract
on the stability, what are we to do?  Does it really matter that both
projects are "open source" if the result will be a product that fails
miserably?

I don't think we can wish those problems away or just pretend that
there's some magic open source dust that'll make everything just work
fine.  The basis of those dependency rules we use isn't some
egg-headed scheme to thwart project teams in their pursuit of release
velocity; it's mother nature.  You depend on it, it changes, you
break.

>   2.2 Originating Community
>     2.2.1 Community Name

I'm not sure about the architectural relevance of this part,
particularly the licensing question that specially calls out GPL
(which version?).  (Is there some other consumer of this checklist
... ?)

>       If conflicts exist then will this project install under /usr/gnu?
>       [ ] Yes
>       [ ] No - ARC review required
>       [ ] N/A

Note that this option is available _only_ for FSF software.  Other
things don't belong in /usr/gnu, even if they're released under one of
the many GPL licenses, at least per the existing approved cases.

>       Are any components shared with other Free Open Souce Software (FOSS)?

Nit: s/Souce/Source/

>       If yes are these newer versions being delivered?
>       [ ] Yes
>       [ ] No - ARC review required

What newer versions?  (Something's missing, because this question
doesn't flow with the previous question ... it's assuming a newer
version of something, but I'm not sure what.)

>       If yes then are the setuid/setgid privileges handled by the use of roles?
>       [ ] Yes
>       [ ] No - ARC review required

I might be missing something here, but since RBAC is currently a
Solaris-only facility, doesn't this at least imply that we're either
forcing changes upstream or forking?

(I thought the whole thrust of this proposal was to avoid changing
anything ...)

>       Do the components create audit logs detailing what took place including what event
>       took place, who was involved, when the event took place?
>       [ ] Yes
>       [ ] No - ARC review required

The current policy doesn't require just any old audit logs, but
instead requires the use of Solaris Audit Trails.  As an architectural
matter, I don't think I agree with fragmenting the audit
infrastructure by allowing open source projects to write audit records
through other, disconnected mechanisms (such as syslog or flat files).

Doing that significantly weakens the value of the Solaris auditing
facility.

Requiring proper auditing forces project teams to change things.  :-<

>   Brief Interface Classification definitions

Omitted from the list is the generally quite useful Consolidation
Private.  Is that intentional?

Not sure that I fully agree with the summaries here, but I suppose
it's ok as long as there's a pointer to the full descriptions.

-- 
James Carlson, Solaris Networking              <james.d.carlson at sun.com>
Sun Microsystems / 35 Network Drive        71.232W   Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757   42.496N   Fax +1 781 442 1677