Login | Register For Free | Help
Search for: (Advanced)

Mailing List Archive: OpenStack: Foundation

Technical committee Technical committee

 

 

OpenStack foundation RSS feed   Index | Next | Previous | View Threaded


anotherjesse at gmail

Feb 20, 2012, 12:32 PM

Post #1 of 3 (268 views)
Permalink
Technical committee Technical committee

Hi,

Perhaps it would be useful to share the the problems / issues you are
trying to improve. My reading is that TC = PBB 2.0

* without appointed seats (PTLs or RAX appointed)
* attendance requirements

I'm particularly worried about the idea that PTLs aren't automatic.
What does it mean to allow decisions to made by the TC that a project
technical lead aren't inherently part of?

Thanks,
Jesse Andrews


markmc at redhat

Feb 20, 2012, 1:17 PM

Post #2 of 3 (246 views)
Permalink
Technical committee Technical committee [In reply to]

Hi Jesse,

On Mon, 2012-02-20 at 11:32 -0800, Jesse Andrews wrote:
> Hi,
>
> Perhaps it would be useful to share the the problems / issues you are
> trying to improve. My reading is that TC = PBB 2.0
>
> * without appointed seats (PTLs or RAX appointed)
> * attendance requirements

Same reading here, but also:

* emphasis on wider discussion before TC level voting

> I'm particularly worried about the idea that PTLs aren't automatic.
> What does it mean to allow decisions to made by the TC that a project
> technical lead aren't inherently part of?

Good question - e.g. if the TC votes that all projects should adopt the
AwesomeDb library as a replacement for sqlalchemy and the PTL (and
perhaps $project-core) disagrees, what then?

I think the answer to that is that the TC is not so much responsible for
making a final call where there is two fundamentally opposing views, but
rather it is responsible for building a rough consensus. TC voting
should perhaps be about whether the TC think a rough consensus has been
reached on a given topic.

A PTL vehemently opposed to a given proposal is a signal that more work
is needed. If the PTL is on the TC and a majority of the TC members vote
against the PTL, that doesn't mean a consensus has been reached.

A PTL has a strong veto power irrespective of his ability to vote on the
TC. Also, $project-core members have somewhat of a veto power with the
ability to -2 a review.

IMHO, this is all very healthy. We don't want the TC to be a group of
individuals making far reaching decisions without building a rough
consensus between the main players.

Cheers,
Mark.


thierry at openstack

Feb 21, 2012, 3:48 AM

Post #3 of 3 (245 views)
Permalink
Technical committee Technical committee [In reply to]

Mark McLoughlin wrote:
> On Mon, 2012-02-20 at 11:32 -0800, Jesse Andrews wrote:
>>
>> Perhaps it would be useful to share the the problems / issues you are
>> trying to improve. My reading is that TC = PBB 2.0
>>
>> * without appointed seats (PTLs or RAX appointed)
>> * attendance requirements
>
> Same reading here, but also:
>
> * emphasis on wider discussion before TC level voting

It is my attempt to translate what the proposed Structure document says
about the TC (no appointed seats, no automatic PTL seats) into a set of
more precise bylaws we can use.

Your analysis of PPB 2.0 is correct, though it also misses:

* Static number of seats (no committee bloat)

>> I'm particularly worried about the idea that PTLs aren't automatic.

I think that's necessary. As we split projects into more manageable and
engaging parts, the current system doesn't scale. What's the point of
voting if the Melange PTL has the same impact as the Nova PTL (no
offense meant). If you split Nova-volume out of Nova, you suddenly
create a new seat ?

As I say in the document, the PTLs are still very much part of the
discussion and can certainly influence the decisions. But when it comes
down to a vote, only the 9 elected people cast their vote. That's fair
and balanced.

>> What does it mean to allow decisions to made by the TC that a project
>> technical lead aren't inherently part of?
>
> Good question - e.g. if the TC votes that all projects should adopt the
> AwesomeDb library as a replacement for sqlalchemy and the PTL (and
> perhaps $project-core) disagrees, what then?

I don't think it's very different from the case where PPB 1.0 decides on
something that a given PTL disagrees with. The PTL voices his opinion,
tries to convince enough voting members, but may fail in doing so. The
fact that he himself is or is not voting is almost orthogonal to this.

> I think the answer to that is that the TC is not so much responsible for
> making a final call where there is two fundamentally opposing views, but
> rather it is responsible for building a rough consensus. TC voting
> should perhaps be about whether the TC think a rough consensus has been
> reached on a given topic.
>
> A PTL vehemently opposed to a given proposal is a signal that more work
> is needed. If the PTL is on the TC and a majority of the TC members vote
> against the PTL, that doesn't mean a consensus has been reached.
>
> A PTL has a strong veto power irrespective of his ability to vote on the
> TC. Also, $project-core members have somewhat of a veto power with the
> ability to -2 a review.
>
> IMHO, this is all very healthy. We don't want the TC to be a group of
> individuals making far reaching decisions without building a rough
> consensus between the main players.

The power is ultimately in the hands of the developers. My guess is that
the situation will not happen, but here are the checks and balances: The
PTL still decides what his project will ultimately do. Developers of the
project can elect a new PTL or fork. And in case of repeated and
unsolvable problems, the TC can decide to remove the "core" status of a
project if the way a given project wants to go and the way "OpenStack"
wants to go are not reconcilable.

--
Thierry Carrez (ttx)
Release Manager, OpenStack

OpenStack foundation RSS feed   Index | Next | Previous | View Threaded
 
 


Interested in having your list archived? Contact Gossamer Threads
 
  Web Applications & Managed Hosting Powered by Gossamer Threads Inc.