Hi Nico, thanks for starting this thread (and removing ARC number) because the comments are generic now, not relevant to the case:
On 08/24/09 18:16, Nicolas Williams wrote: > The comments about /contrib are great and all, but, are they > architecture? If the i-team wants to proceed, can this case be > [derailed and then, ultimately,] denied? > > If an i-team asserts "Linux familiarity" to get past bikeshed paint > distaste, on whose shoulders is the burden of proof: ARC members' or the > i-team's? > > But this case was not "Linux fam" case (and it was not declared in ARC materials I think). Btw. "Linux fam" is still very vague (who is the authority saying "something is Linux fam case"?). > Going by past ARC history I'd say that the complaints so far in this > case are about design, not architecture, therefore if the i-team > insists and there are no architectural problems, then their case must > get approved. > > Isn't "unneeded additional thing" architecture thing? Is ARC really only about "API"? It is also about the product architecture. > But the questions raised are worth debating (though probably not in this > case's record). Is the /contrib suggestion about bloat in SXCE/Nevada? > bloat in the pkg list in /release? about Solaris being better than Linux > by treating FOSS like the FOSS in this case as icky? But surely the ick > factor is not just about us being snobs -- Linux distros tend to > differentiate between must-have FOSS and Joe's random small bit of FOSS, > and if they can make such choices, why not us too? But who shall be > judge? Right now it could only be the ARC, even though that's not been > its job in the past. > > Maybe not ARC, maybe P-team? But yes, the evaluation about release (must-have) vs. contrib (random bints) should be done by some board, as part of the Product architecture. Maybe splitted from ARC, otherwise ARC will remain Sun-centric board and not OpenSolaris project dedicated. > Another question that may arise is the architectural status of /contrib > (e.g., can the ARC bless integrations into /contrib in some manner that > confers, say, protection to filesystem namespace camping in /contrib? > do interfaces in /contrib have to advertise stability attributes? > etcetera). > > IMO: Integrate it all, and let users sort it out (a paraphrase of a > Spanish inquisitor quote) (e.g., with a voting scheme). If an > i-team can't commit to interface stability, then make all public > interfaces Volatile, and mark the package as "toxic interface > stability", see if users still want it :) > > And who will sustain such thing for the next 10+ years? ARC is looking at effectivness Sun Engineering resources. Pushing something to repository does not mean end of issue, it is the cheapiest thing. Best regards, Milan
