On Fri, 2009-07-10 at 10:14 -0500, Mark Martin wrote: > Is there any notion of how much review cases will get going in to or > coming from /contrib? Would it be clear to package contributors and > maintainers that it is prudent that their contribution undergo some > review? Does someone act in a reactionary mode and simply monitor > contrib and spawn cases for contributions that warrant review due to > their intimacy with the OS? > > For example, if I ever got around to completing my port of OpenVPN via > the juicer and /contrib, I'd expect that particular package would > warrant a PSARC review. But I could just claim laziness and "submit it > and forget it". I don't see any checks in place to assure sane > architecture on my contribution in that process. What am I missing? Is > ARC reserved only for projects that originate within Sun? For the > unwashed masses that contribute via /contrib, do they care about ARC?
I don't think that Sun has anything to do with it. The distinction you're trying to make (I think) is the barrier to entry to various repos as far as quality is concerned, and not which company threw it over the wall. AFAIK, the contrib repository, by definition, contains a bunch of packages that are not guaranteed to having been tested nor reviewed by anyone. There's a disclosure to that effect on the repo web page. The dev and release repos have barriers to entry that include things like architecture, design, and code reviews. The consolidation C-Teams protect that barrier. > My understanding was that it is now very easy for folks to simply find > the magic configuration spec script, submit it to the juicer, and that > more or less becomes an available package via /contrib. Is the notion > that Sun teams might cherry pick from /contrib, tweak the spec and > submit an ARC case, and then integrate more /fully/ by actually > integrating source into a consolidation (shedding the skin of a spec file)? Again, I don't see what Sun has to do with this. Anyone can go through the process integrating code into a consolidation. Can we focus on the architectural distinctions between the repo's in this discussion, and not on which company has the greatest ease of integrating into them? That's totally irrelevant to the discussion, although not unimportant in the grand scheme of things. -Seb
