openstack team mailing list archive

[Thierry Carrez <thierry@xxxxxxxxxxxxx>]

Doug Hellmann wrote:
> 
> On Wed, Jul 18, 2012 at 7:00 PM, Thierry Carrez <thierry@xxxxxxxxxxxxx
> <mailto:thierry@xxxxxxxxxxxxx>> wrote:
> 
>     Mark McLoughlin wrote:
>     >> Making our multiple projects converge onto consolidated and
>     >> well-accepted APIs is a bit painful work, but it is a prerequisite to
>     >> turning openstack-common into a proper library (or set of libraries).
>     >>
>     >> I'd say the whole thing suffers from not having a proper
>     >> team/leader/coordinator dedicated to it: relying on existing,
>     >> overstretched PTLs to lead that effort might not be the fastest path.
>     >
>     > While I was on vacation, I read in the weekly newsletter:
>     >
>     >   "It developed into a request for leadership for openstack-common"
>     >
>     > and was like "WTF do you call the work that e.g. I, Jason, Russell and
>     > Doug have been doing?"
>     >
>     > But I see your point is a little different - you feel there should
>     be an
>     > elected/appointed "PTL without a PPB vote" or whatever to
>     represent the
>     > project. I guess that could help clarify things since it's what folks
>     > are used to with other projects.
> 
>     Right. So far we said that openstack-common was driven by "all the
>     PTLs", but that didn't prove particularly fast and efficient. Having a
>     clear face associated with it, someone specific taking the "lead" on
>     this project, will, I think, help a bit in getting to the next step.
> 
> 
> 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.

[ Avoiding the need to distinguish between "worthy" and "unworthy"
projects leads was one of the many reasons why I preferred the TC to be
completely directly-elected. ]

-- 
Thierry Carrez (ttx)
Release Manager, OpenStack