Specific replies on this proposal:
* namespace collisions... I'm not sure what level, if any, IPS has to
separate out namespaces for different "expectation levels". I presume
we are talking about separation of installable packages -- conflicts in
actual *installed* bits are allowed, right?
* "expectation level" -- we need a better term here, although I'm not
sure what would be best
* I do like how you have separated out the levels, although I'm not sure
there is a lot of merit in separating out Sandbox from Prototype. (In
particular, more detail explaining what the difference between these
levels would be needed.)
* In Project Behavior, I think it should be permissible for ARC and a
project to explicitly agree to demote (or maybe even promote) a project
-- its not unreasonable for a project to try for a higher commitment
level, and discover that there are some key reasons why such a level is
untenable (though one hopes that projects will mostly "choose correctly".)
* Finally, thank you for taking this on!
-- Garrett
John Plocher wrote:
> [Replies to arc-discuss only, please]
>
> Bart Smaalders wrote:
> > > Perhaps you could simply accept that we're going to have a networked
> > > repository,
>
> Brian Utterback wrote:
>> Nobody says we have to wait until the repository is up and running.
>> The real issue is that it is impossible to do the architectural
>> review without knowing the characteristics and requirements of the
>> repository.
>
> Enough grandstanding and obstructionism.
>
> I'm stepping up to define their project requirements for this mythical
> and yet steamrollered repository - at least those that come from the
> ARC's perspective.
>
> Of course, I need your help :-) Please review/update the following
> to capture the points that you feel that the ARC needs in order to
> review and categorize these FOSS cases. We can talk about this
> tomorrow in PSARC if needed.
>
> Once this is relatively complete, I will submit it as a fasttrack.
>
> -John
>
>
> Wiki:
>
> http://www.genunix.org/wiki/index.php/ExpectationTaxonomy
>
> 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]
> 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
> 3. It must allow the user to select which expectation
> level(s) to choose packages from for installation
>
> 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"
> 2. Projects that do not meet the requirements for their
> expectation level will be denied. Denied projects
> may not go into any repository.
> 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.
> * Experimental tagged projects are expected to be ARC
> "SelfReview" closed approved automatic fasttracks.
> They exist simply to record the package name and version.
> * 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.
