openstack team mailing list archive

[Jay Pipes <jaypipes@xxxxxxxxx>]

On 08/02/2012 04:05 PM, Eric Windisch wrote:
> On Monday, July 23, 2012 at 12:04 PM, Doug Hellmann wrote:
> 
>>>> Sorry if this rekindles old arguments, but could someone summarize the
>>>> reasons for an openstack-common "PTL" without voting rights? I would
>>>> have defaulted to giving them a vote *especially* because the code in
>>>> common is, well, common to all of the projects.
>>>
>>>
>>> So far, the PPB considered openstack-common to be driven by "all PTLs",
>>> so it didn't have a specific PTL.
>>>
>>> As far as future governance is concerned (technical committee of the
>>> Foundation), openstack-common would technically be considered a
>>> supporting library (rather than a core project) -- those can have leads,
>>> but those do not get granted an automatic TC seat.
>>
>>
>> OK, I can see the distinction there. I think the project needs an official leader, even if we don't call them a PTL in the sense meant for other projects. And I would expect anyone willing to take on the PTL role for common to be qualified to run for one of the open positions on the new TC, if they wanted to participate there.
> The scope of common is expanding. I believe it is time to seriously consider a proper PTL. Preferably, before the PTL elections.

No disagreement from me.

> The RPC code is there now. We're talking about putting the membership services there too, for the sake of RPC, and even the low-level SQLAlchemy/MySQL access code for the sake of membership services. A wrapper around pyopenssl is likely to land there too, for the sake of RPC. These are just some of the changes that have already landed, or are expected to land within Folsom.

What do you mean by "membership services"?

> Common contains essential pieces to the success of OpenStack which are currently lacking (official) leadership. Everyone's problem is nobody's problem.
> 
> Consider this my +1 on assigning a PTL for common.

Sure, me too.

-jay