On Tue, Aug 07, 2007 at 10:44:12AM -0700, Stephen Lau wrote: > > LDoms is not a project - it is a community of people who are working on > > numerous projects related to the LDoms family of products. > > > > This will involve at a minimum the SPARC hypervisor, Solaris driver > > projects, domain manager projects, management tools, migration tools, > > installation tools, backup tools etc. ... please note the plurality of > > projects in each of these areas. There will likely be dozens of projects > > (since there are already dozens of projects even within the Sun internal > > development team) - this will (hopefully) only increase as we get wider > > community engagement. > > > > Each of these projects will have their own milestones and code drops - > > and will come and go over time. > > > > As such, LDoms exactly fits your definition of a community - and should > > have its own governing board and project level coordination. > > And are all those projects ready to be initiated and started now? Do > you have content? Are you truly ready for open development, open > design, etc.? > > If so, then great. I'll be happy to vote for an open LDoms Community > Group with tons of content ready to go, with projects ready to be > instantiated and endorsed - and lots of open discussion and design on > multiple mailing lists. > > For the very same reason people inside of Sun don't get to start out > with their own huge consolidation, or their own C-team, or their very > own ARC - I don't see why you want to start out with a Community with > your own governance representation. What's your opposition to starting > out smaller with a defined scope and then growing?
For what it's worth, I agree completely with Ashley - LDoms does incorporate many different projects. I don't see it as a project itself. That said, my question (and apprehension about approving this CG) is whether LDoms is the *right* CG. Unfortunately the perception seems to be, with some justification, that existing CGs are precedents. That's unfortunate, because most existing CGs predate any semblance of discrimination or coherency. Again, I realise it's frustrating to see that Xen and Zones are CGs and then get probing questions about the appropriateness of creating an LDoms CG. If those product teams came to us today, we'd be asking them the same questions. Anyway, the team seems to have its head on straight about projects and community groups, so I'm leaning toward supporting this. But I would like to see the LDoms team talk further with John Levon and the Xen team about something along these lines: 1. Rename Xen to Virtualization 2. Create some kind of sub-Group structure for managing separate interest areas. 3. Agree on a list of LDoms-related Core Contributors and issue them grants. 4. Create and endorse the "Initial Xen Integration" project (which would provide hosting for project materials, source code, etc. for the Xen project team). 5. Create and endorse additional LDoms-related projects as specified by either the CG as a whole or a suitable working group. 6. Open negotiations with the Zones and BrandZ Community Groups for a broader merger. This could be done after forming an LDoms CG, but once we approve a CG, we have no means of encouraging anyone to pursue a merger. Again, if you feel that such a structure is not appropriate or would hinder your progress, this is the time to make that argument. -- Keith M Wesolowski "Sir, we're surrounded!" FishWorks "Excellent; we can attack in any direction!"
