+1
Cheers,
Christopher Ferris
IBM Distinguished Engineer, CTO Industry and Cloud Standards
Member, IBM Academy of Technology
IBM Software Group, Standards Strategy
email: chris...@us.ibm.com
Twitter: christo4ferris
phone: +1 508 234 2986
Cheers,
Christopher Ferris
IBM Distinguished Engineer, CTO Industry and Cloud Standards
Member, IBM Academy of Technology
IBM Software Group, Standards Strategy
email: chris...@us.ibm.com
Twitter: christo4ferris
phone: +1 508 234 2986
-----openstack-bounces+chrisfer=us.ibm....@lists.launchpad.net wrote: -----
To: Doug Hellmann <doug.hellm...@dreamhost.com>
From: Eric Windisch
Sent by: openstack-bounces+chrisfer=us.ibm....@lists.launchpad.net
Date: 08/02/2012 04:59PM
Cc: Thierry Carrez <thie...@openstack.org>, openstack@lists.launchpad.net
Subject: Re: [Openstack] best practices for merging common into specific projects
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.
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.
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.
Regards,
Eric Windisch
_______________________________________________
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help : https://help.launchpad.net/ListHelp
From: Eric Windisch
Sent by: openstack-bounces+chrisfer=us.ibm....@lists.launchpad.net
Date: 08/02/2012 04:59PM
Cc: Thierry Carrez <thie...@openstack.org>, openstack@lists.launchpad.net
Subject: Re: [Openstack] best practices for merging common into specific projects
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.
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.
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.
Regards,
Eric Windisch
_______________________________________________
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help : https://help.launchpad.net/ListHelp
_______________________________________________ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
