Open Stack

On 05/31/2013 07:49 AM, Monty Taylor wrote:
>
>
> On 05/31/2013 06:21 AM, Thierry Carrez wrote:
>> John Dickinson wrote:
>>> As a smaller category list:
>>>
>>> Compute (eg Nova, Glance)
>>> Storage (eg Swift, Cinder)
>>> Networking (eg mutnauQ)
>>> CI/QA/Docs (eg CI, tempest, docs)
>>> Operations (eg Horizon, Heat, Ceilometer)
>>> "cross project" (eg oslo, keystone)
>>>
>>> This certainly isn't a perfect list, but it's an alternative that has some strengths. [...]
>>
>> The main issue I see with the "category" model (whatever the precise
>> list is) is that it freezes the relationship between projects and the
>> relative weight of their representation. Your list for example sets in
>> stone the following statements: "Storage is as important as Compute",
>> "Release management or vulnerability management should never be
>> represented in the TC" and "most future projects will not get their own
>> seats but will have to share the Operations seat(s)".
>>
>> The risk is to grow a Technical Committee that is not representative of
>> the body of current OpenStack contributors. You could argue that we
>> don't care and that "the list" is how we want to freeze influence of
>> each category into the TC forever... But having an oversight body that
>> is no longer seen as representative of the body of contributors is how
>> most projects end up having a fork to change their governance.
>>
>> I've seen that happening in other projects I've been involved with...
>> and personally I think we should make our best to prevent that from
>> happening. This is why I favor more "representative" models like the
>> "Best 7 PTLs + 6" or the "All-directly-elected 11" models.
>
> Honestly, I think John's list isn't bad (it's not perfect, and it never
> will be - why are docs and CI in one? on the other hand, why not? meh...)
>
> I think what it points out to me is that what I want is:
>
> Some amount of direct representation - because populist democracy is good
> Some amount of categorical representation - because populist democracy
> is bad
>
>
> So I'm in favor of either the "Base 7 PTLs + 6 direct" but ... what if
> we combine the two and have a rep from each of a set of categories
> (similar to John's category list) and then a set of direct.
>
> The point of the categories isn't to make the TC rep for the category an
> über-PTL for the projects under it - it's to ensure that:
>
> a) Nova doesn't get all the seats
> b) It's harder for a single company to buy the TC by employing a bunch
> of devs (if they do, they'll have to buy enough devs that they are
> providing adequate coverage in all of the categories - so good on them)

For that to be the case, one company would need to have ~300 active devs 
on OpenStack (which is at least a 6x increase from all the top 
contributing companies). If one organization is really contributing 1/2 
the labor force to the project, and no other organization(s) stepped up 
to share some of the burden, we've got much bigger issues than TC 
representation.

> How about:
>
> Compute (eg Nova, Glance)
> Storage (eg Swift, Cinder)
> Networking (eg mutnauQ)
> CI/QA/Docs/Release (eg CI, tempest, docs)
> Operations (eg Horizon, Heat, Ceilometer, TripleO)
> Cross Project (eg oslo, keystone, reddwarf)
>
> + 7 directly elected?

It feels like complexity here is the enemy of transparency. Is Monty a 
CI, TripleO, or oslo rep? It gets complicated quickly. Does mikal run as 
oslo vs. nova? And does he pick in advance because his chances are 
better in one than the other?

It also feels to me like we're going to have to adjust categories every 
6 months to a year to match the changing focus of the project, otherwise 
we encode in rules something which is better off letting the community 
just decide on over time.

And if that's true... why not just give the flat 11 a shot. If it seems 
to work, cool. Super low maintenance, no bikeshedding on categories, no 
PTL growth concerns blocking things from getting incubated.

If not, in 6 months or a year we revisit. Which we'd have to do on any 
category based model anyway. If OpenStack has taught me anything, it's 
that predicting where OpenStack is going to be in a year is really hard. 
Encoding the future structure of the TC, based on a snapshot of what 
OpenStack seems to care about today, just seems doomed to unoptimal results.

	-Sean

-- 
Sean Dague
http://dague.net