On Mon, Jun 04, 2007 at 02:39:46PM -0400, Brian Gupta wrote: > I had posted an idea the other day regarding setting up a sandbox/misc > community, where there is a minimal barrier to entry as regards to setting > up a project mailing list. (This is mostly for projects that do not fall > neatly within the scope of an existing CG.)
Given that there are over 40 Community Groups, it's a bit of a stretch to think that not a single one of them could possibly be interested in a particular idea. Also, any Community Group can set up mailing lists for proto-project discussion (or incubation, if you feel the need to say as Apache says) at any time, with no process, no announcement, no restrictions or permission required from anyone. When I think of something that should be a project, I can express its goal as "integrate this thing into some consolidation" or "implement some piece of code that does a certain thing" or "document this feature" or even "host a conference on this topic in November." Note that the level of specificity and detail can vary broadly, as can how far along the team happens to be at the time they wish to exist, formally, as a project. On the other hand, when I think of something that should be a Community Group, I think of people whose goals might be expressed as "improving the state of the art in this area" or "offering leadership and guidance to people working in some vertical slice of the system" or perhaps "learning about and sharing tips on these features, and perhaps improving them." I think once you accept this distinction, recognise the uses of Groups' self-government rights, and reject the false assumptions I alluded to above, the need for a special Community Group to sponsor lighter-weight projects is pretty clearly nonexistent. In this case, then, it seems to me that the proposal is well-formed and properly-scoped - clustering clearly is its own interest area in which a number of useful projects are possible and in which a certain group of people will be able to offer its expertise to others wishing to work within it. My concerns here stem more from the fact that SunCluster is not a part of OpenSolaris, nor of Solaris. If the intent is to integrate support for HA clustering into OpenSolaris proper through a series of projects aimed at incorporating the needed support into ON and other consolidations, then improving that work over time, a Community Group definitely sounds like the correct abstraction. If the intent is just to capitalise on OpenSolaris as another venue for marketing a Sun product (open source or not) and "capturing developers", then I don't really feel it's appropriate at all. But in the latter case, a project would be no more appropriate, whether in some Incubator Community Group or any other. And while a project usually has code (or, more generally, artifacts) it produces for aggregation and integration by distributors, a Community Group does not. So it's fine for this Group to have no code initially; it will presumably sponsor projects which do. I suppose the core of my question, then, is this: would it be this Community Group's intent to enhance and improve support, via projects, for HA clustering in OpenSolaris? Or would its intent be to itself manage and distribute additional source (perhaps as an additional consolidation, perhaps in some other as yet undefined structure) providing that support? -- Keith M Wesolowski "Sir, we're surrounded!" FishWorks "Excellent; we can attack in any direction!"
