[arc-discuss] Discussion requested for a new ARC Policy on "Expectation Taxonomy and Repository Requirements"

[Stephen Hahn]

* John Plocher <John.Plocher at Sun.COM> [2008-04-16 04:30]:
> Wiki:
> 
> http://www.genunix.org/wiki/index.php/ExpectationTaxonomy
 
  I don't actually agree that expectation is the architectural axis we
  should be pursuing.  I'm much more concerned with people building on
  different, but similar components that have identical stabilities (and
  may have completed all aspects of the current process for).  For
  instance, we presently would allow a command in /usr/bin to be
  implemented in anything from assembly, through the compiled languages,
  to Python, Perl, or even PostScript...  (More interpreters are coming,
  so this decision will get more costly.)  Similar choice exists in XML
  parsers, HTTP retrieval utitilies, and so on.  Allowing such choices
  presents costs to the initial implementing team, later maintainers, and
  anyone participating in the service chain.

  Control of these costs was the point of a "Preferred" architectural
  attribute: to assign an implementation preference to a subset of the
  architecturally reviewed components.  It's not the right term for a
  component that has some, but not all, of the attributes the
  development process attempts to assign.  It's also not a statement
  about whether a system requires the presence of the component to be
  functional.

  (I would also like to reserve Core as a specific
  metacluster-equivalent, rather than a package label.)
  
  One aspect that doesn't seem clear is that some attributes are of
  importance to some consumers, but not others.  The ability to filter
  out components on locally-set filters seems more important than some
  coarse grouping.  I even wonder if the groupings will get in the way
  of those aspects.

  I'll make further comments below, but I feel I must to point out that
  non-development process-following repositories are possible and
  likely.  Expect that these particular attributes will not be present
  on a large subset of available packages.
  
> Key section:
> 
> DRAFT Proposal
> 
> The IPS/pkg repository and associated packaging system must
> have the following abilities:
> 
>    1. It must allow packages to be tagged with an "expectation
>       level" taken from the (evolving) set of
>       [Sandbox, Prototype, Experimental, Preferred, Core]

  Yes, such tagging is possible.

>    2. It must treat these expectation levels as namespace
>       qualifiers, such that packages of the same name may
>       coexist in a repository with different expectation levels

  No.  There are numerous ways to do this, but jamming a label into the
  name isn't one to enforce.

>    3. It must allow the user to select which expectation
>       level(s) to choose packages from for installation
 
  Yes, via filters.

> Project Behavior:
> 
>    1. Projects are required to explicitly declare their
>       expectation tag level in the materials submitted for
>       ARC interaction.  The ARC Default will be "Core"

  New label needed.

>    2. Projects that do not meet the requirements for their
>       expectation level will be denied.  Denied projects
>       may not go into any repository.

  Not enforceable.  For instance, project teams and third parties will
  have the ability to operate independent repositories.

>    3. Projects are expected and required to ensure that all
>       packages they create for inclusion into a repository
>       are tagged with the same expectation level presented
>       to the ARC.
> 
> There is a direct relationship between a project's "expectation
> level" and the quality of review it undergoes:
> 
>     * There will be NO ARC review for Sandbox or Prototype
>       projects. Put another way, if your project is not ARC
>       reviewed, it MAY NOT be tagged with anything other
>       than the Sandbox or Prototype tags.

  Why do we need these levels?  Perhaps the absence of the attribute
  should be treated as "below Experimental".

>     * Experimental tagged projects are expected to be ARC
>       "SelfReview" closed approved automatic fasttracks.
>       They exist simply to record the package name and version.

  I believe filesystem namespace management is also needed for any
  component pursuing ARC review of any detail.

>     * There will be some [subset TBD] level of review, and
>       some [subset TBD] set of big rules, ARC policies and
>       related requirements applied to Preferred projects, and
>  
>     * There will be a full set of ARC and Solaris Policy,
>       Big Rule and Review expectations applied to Core
>       projects. It is expected that this level will require
>       a large long term engineering commitment from Sun
>       and that the resulting project will be fully and
>       completely integrated into Solaris, using all of
>       Solaris' native feature sets.
 
  I made comments about completeness above, but I'll restate them:  it
  seems to me, that as some components achieve greater adoption, we
  might want to smoothly acquire compliance with a larger number of the
  "Big Rules".  Separating the two classes on the lack of compliance
  with any single Big Rule seems wrong.  (How would you handle waivers?)

  - Stephen

-- 
sch at sun.com  http://blogs.sun.com/sch/