[I've updated http://www.genunix.org/wiki/index.php/ExpectationTaxonomy]
Stephen Hahn wrote: > * 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 There may well be other axis that are important as well. While I'm not addressing them, you certainly can :-) In this specific situation, the ARCs are faced with 50 to 500 projects that are saying that they are special, and so do not have to comply with [some random set of] ARC and C-Team policies and expectations. The ARCs are being told by project teams that We are simply compiling some piece of FOSS, we are not investing any engineering resources in changing it in any way to work on OpenSolaris (even if it needs it), the normal Solaris rules (localization, security, IPv6,...) don't apply to us, and we don't wish to incur any review process overhead In other words, how can we (all) create and populate a [set of] repositories that have attributes that meet our needs and can scale to dozens of repos each with [tens of] thousands of packages while at the same time not overwhelming ourselves or the projects with unwanted and unneeded process? Answer: Use the pkg tagging mechanism to identify packages that have chosen to spend the effort on integrating well into OpenSolaris. Build the tagging into our review processes so that it actually means something. Get out of the way of project teams who don't value such integration. > Control of these costs was the point of a "Preferred" architectural OK, so I'll use different terms: s/Core/Integrated/g s/Preferred/Aggregated/g > I even wonder if the groupings will get in the way of those aspects. I see multiple "tag types" as being valuable, not just this "ARC Review Expectations" one. The "ARC" one is interesting here because it can help us get out of this expectation mismatch mess. > I'll make further comments below, but I feel I must to point out that > non-development process-following repositories are possible and > likely. Agreed. This was focused on "our" repositories. > No. There are numerous ways to do this, but jamming a label into the > name isn't one to enforce. OK >> 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. Changed to: # Projects that do not meet the requirements for their OpenSolarisIntegrationLevel will be denied. As a matter of intentional community policy, Denied projects may not go into any Sun or OpenSolaris maintained repository. > Why do we need these levels? Perhaps the absence of the attribute > should be treated as "below Experimental". Noted. This is all about setting and living up to expectations. If you don't have any (i.e., absence of attribute), how can you live up to them? Architecture is doing things by intent, not reacting to accidentally created confusion... > I believe filesystem namespace management is also needed for any > component pursuing ARC review of any detail. Noted. Some of these levels are there for projects that are taking a path that avoids ARC review at /any/ level of detail, so for those, such management would be inappropriate. > 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?) I'd have the set of allowed waivers explicitly enumerated as part of the "Aggregated" class[1]; it does not make sense to claim that something is tightly integrated and yet apply waivers that allow it be less than really integrated. "Truth in advertising" "Integrated" means following all the applicable rules with no waivers. -John ____ [1] Maybe there needs to be more granularity here - one level per big rule waived? Maybe each big rule is its own attribute? ... The three actionable categories I an trying to accommodate are [tightly integrated, somewhat integrated, everything else]
