On Fri, Jul 10, 2009 at 10:43 AM, Sebastien Roy<Sebastien.Roy at sun.com> wrote: > On Fri, 2009-07-10 at 10:14 -0500, Mark Martin wrote: >> 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. >
My apologies, I wasn't really trying to draw distinctions between Sun per se, but rather the processes. I'm still confused how you can draw any lines of any sort between repo and consolidation. The process for a any contributor, /as I understand it today/, to contribute a package to OS is driven by two possible choices: 1) Provide a spec file, go through the /pending -> /contrib process. Go eat breakfast. There is no consolidation. There's no source, per se, to check in. It's primarily a configuration driven task. Your contribution makes it into The OpenSolaris(tm). You're free to tell folks to grab your goodies from /contrib and walk away. And yes, I realize part of source juicing means probably uploading patches. 2) Find an appropriate consolidation, ARC, go through the contrib-sponsor process (or bypass parts depending on origination). Go eat lunch. There's definitely a consolidation. There's mercurial and workspaces and such. Your contribution makes it into The OpenSolaris(tm) and possibly others. Assuming that's true, then it also follows that folks from the OS community "at large" are likely choosing #1, which I'll note has no ARC associated it with. If they're not choosing that, then they're certainly being shepherded to do it. The folks from the OS community coming from the internal process are following #2. Am I wrong in seeing that there's no coverage for the gap between the 2 processes, which includes: - ways to integrate - quality of integration - quality of code review - architectural integration review Assuming you narrow the scope of discussion to: "how do things go from /contrib to /dev and /release", then the fundamental question I asked about who does this remains. The original package submitter? Some entity who is staffed and funded to provide ongoing maintenance and has a vested interest in seeing things make the quality+integration assurance leap? Does the leap mean it goes from .spec file to (determine a consolidation, tweak sources, ARC, RTI?) Do the original package maintainers wash their hands of the package once it makes the leap (and stay on as maintainers if it never leaves /contrib)?
