LSARC/2008/061 - Indiana check list

[James Carlson]

John Fischer writes:
> You are correct that any external open source project could use
> this check list.

OK; that alleviates probably the biggest of my concerns: having a set
of "special rules."

>  This is an attempt to help us, the ARCs and
> specifically LSARC, deal with the expected influx of cases that
> have the delivery mechanism of Indiana.

Unfortunately, at least in architectural terms, I have no clue what
that "delivery mechanism" means.  What type of release is Indiana,
anyway?

How can we approve the integration of projects when we don't know what
the constraints on the interface changes might be?  In other words,
"Committed" behaves one way in a "Minor" release, but quite another in
a "Major."  If we don't know what we have, then we can't actually say
much about the changes.

> could be any external open source project.  The idea is that the
> project team would fill out the check list and then submit the
> paper work to sac as an automatic closed case.  This way we still
> have a record of the interfaces.

I didn't see anything in there about the stability of interfaces
versus usage context (e.g., project and consolidation boundaries) and
dependencies.  We could codify the existing rules fairly easily for
the checklist, but would this just create more trouble?

	For each other project [library, et cetera] that you depend
	on, obtain the stability levels and delivering consolidation
	for that other project, and check against this list.  ("Fail"
	means "needs explicit review.")

	Other stability  Consolidation  Release Vehicle  Result
	---------------  -------------  ---------------  ------
	Any              Any            Major            Fail
	Committed        Any            Not Major        OK
	Uncommitted      Any            Minor            Fail
	Uncommitted      Any            Patch            OK
	Volatile         Same           Any              OK
	Volatile         Other          Any              Fail
	Cons. Private    Same           Any              Fail
	Cons. Private    Other          Any              Fail
	Proj. Private    Any            Any              Fail

(Well, something like that.)

> Now the basic premise of this check list is that these interfaces
> are defined at some stability level (mostly Volatile, though not
> necessarily), adhere to our security standards and installation
> location.  If the project teams can not give these basic assurances
> then they must seek further review.  Most of the questions revolve
> around various security Best Practices or Policies and the Gnu
> installation location PSARC case.

There seem to be other assumptions here -- perhaps that the
dependencies on other projects will just work themselves out (perhaps
in some other forum rather than the ARC).

> Now in terms of open vs. closed.  It could also be used for
> closed projects but since we control of those projects then we
> can do a better review.  They should also adhere to more then just
> security and installation location Sun standards.

I wasn't talking about any projects we "control."

Instead, I was talking about "open source" versus "source purchased
from some vendor."  In terms of this checklist, and the rationale
behind it, those two cases seem like the same thing to me -- they're
both instances where we have no authoritative "control" over the way
the software is developed.

In truth, I don't think that control is or ever was an architectural
matter, but since it's a (puzzling) part of this proposal, I was
commenting on how it seems to have nothing to do with whether that
externally-obtained source is itself developed in an open or
proprietary manner.  It's more of a "found software" checklist.

-- 
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