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