[ogb-discuss] You have been nominated for the OpenSolaris Structure Reorg sub-commmittee

[Bonnie Corwin]

John Plocher wrote:
> Bonnie Corwin wrote:
>> I must be missing something, so apologies in advance, but I continue 
>> to not understand this.
>>
>> Projects have code associated with them.  And Projects decide how to 
>> manage associated putbacks and commit rights.
>>
>> This means a consolidation is a large project.  It has a consolidation 
>> gate and it has processes/requirements for putbacks and will grant 
>> commit rights - just like smaller projects do.  The fact that other 
>> projects contribute to the larger project shouldn't matter to this 
>> discussion.  And specifics about Cteams or other organizational detail 
>> shouldn't matter for this discussion either.
>>
>> What am I missing?
> 
> I don't think you are missing anything.
> 
> This is the definition of Consolidation.  We currently build OpenSolaris
> by combining the output of consolidations into distros.  We don't have a
> random collection of independent projects that the world picks and chooses
> from.
> 
> Most of the "Projects" on OS.o today exist to contribute back into one
> of these consolidations.  Very few exist as stand-alone things.
> 
> We have the ON component that has > 100 Projects that feed into it.
> SFW has a few, as do Desktop, Storage, Clustering and X.
> 
> We also have Project Indiana which, everyone agrees, really should
> be another contributer to ON and not a stand-alone effort.
> 
> In terms of the current constitution, I believe that the various
> consolidations should all be Community Groups with Projects below
> them.  If there are any Projects that are/should be "stand alone",
> then we should consider bumping them up to be Community Groups in
> their own right.
> 
> If it helps, think of this as adding "Consolidation" as a synonym for
> Community Group.
> 
>   -John

So everything you've said confirms that consolidations are not special 
in this discussion.  They are simply large Projects.  They manage code 
and they have processes for taking in code.  Projects that deliver to a 
larger project don't need to be nested hierarchically or 'owned' by the 
larger project.  Projects should simply exist.  Where each chooses to 
deliver should not be part of a governance discussion.

I think this whole discussion has gotten confused, and I'd really like 
someone to define exactly what problem we're trying to solve.  We've 
moved from defining top-level collectives that will organize and manage 
themselves to talking about hierarchies that somehow need to be managed.

Why are we not finishing the original discussion to define top-level 
collectives?  Why do we care that consolidations take in other project 
code or that OpenSolaris is built from combining the output (or some of 
the output) from consolidations?  Why does that matter to governance or 
to defining collectives?

Bonnie