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?
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.
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.
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 :)
Nico
--
