Re: [Openstack] best practices for merging common into specific projects

> > Ah, yes. I've urged the team to use the term ServiceGroup instead of the > Zookeeper "membership" terminology -- as membership has other > connotations in Glance and Nova -- for instance, membership in a > project/tenant really has nothing to do with the concept of service > groups that can mo

Re: [Openstack] best practices for merging common into specific projects

On 08/02/2012 08:52 PM, Eric Windisch wrote: >> >> What do you mean by "membership services"? > See the email today from Yun Mao. This is a proposal to have a pluggable > framework for integration services that maintain memberships. This was > originally desiged to replace the MySQL heartbeats i

Re: [Openstack] best practices for merging common into specific projects

Thierry Carrez wrote: > So I support > that move, and will prepare a resolution to adjust the TC charter to > accommodate this change and propose it at the next PPB meeting. Pushed to the PPB's next meeting agenda as: http://wiki.openstack.org/Governance/Proposed/OpenStackCommonException Cheers,

Re: [Openstack] best practices for merging common into specific projects

Mark McLoughlin wrote: > On Thu, 2012-08-02 at 15:47 -0700, Vishvananda Ishaya wrote: >> On Aug 2, 2012, at 1:05 PM, Eric Windisch wrote: >> >>> The scope of common is expanding. I believe it is time to seriously >>> consider a proper PTL. Preferably, before the PTL elections. >> >> +1 > > So, I

Re: [Openstack] best practices for merging common into specific projects

On Thu, 2012-08-02 at 15:47 -0700, Vishvananda Ishaya wrote: > On Aug 2, 2012, at 1:05 PM, Eric Windisch wrote: > > > The scope of common is expanding. I believe it is time to seriously > > consider a proper PTL. Preferably, before the PTL elections. > > +1 So, I guess I've been doing this unof

Re: [Openstack] best practices for merging common into specific projects

> > What do you mean by "membership services"? See the email today from Yun Mao. This is a proposal to have a pluggable framework for integration services that maintain memberships. This was originally desiged to replace the MySQL heartbeats in Nova, although there will be a mysql-heartbeat ba

Re: [Openstack] best practices for merging common into specific projects

+1 On Fri, Aug 3, 2012 at 6:47 AM, Vishvananda Ishaya wrote: > > On Aug 2, 2012, at 1:05 PM, Eric Windisch wrote: > > > The scope of common is expanding. I believe it is time to seriously > consider a proper PTL. Preferably, before the PTL elections. > > +1 >

Re: [Openstack] best practices for merging common into specific projects

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 vot

Re: [Openstack] best practices for merging common into specific projects

On Aug 2, 2012, at 1:05 PM, Eric Windisch wrote: > The scope of common is expanding. I believe it is time to seriously consider > a proper PTL. Preferably, before the PTL elections. +1 ___ Mailing list: https://launchpad.net/~openstack Post to :

Re: [Openstack] best practices for merging common into specific projects

+1Cheers,Christopher FerrisIBM Distinguished Engineer, CTO Industry and Cloud StandardsMember, IBM Academy of TechnologyIBM Software Group, Standards Strategyemail: chris...@us.ibm.comTwitter: christo4ferrisphone: +1 508 234 2986-openstack-bounces+chrisfer=us.ibm@lists.launchpad.net wrote:

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 > > > com

Re: [Openstack] best practices for merging common into specific projects

On Mon, Jul 23, 2012 at 12:00 PM, Thierry Carrez wrote: > Doug Hellmann wrote: > > > > On Wed, Jul 18, 2012 at 7:00 PM, Thierry Carrez > > wrote: > > > > Mark McLoughlin wrote: > > >> Making our multiple projects converge onto consolidated and > > >> well

Re: [Openstack] best practices for merging common into specific projects

Doug Hellmann wrote: > > On Wed, Jul 18, 2012 at 7:00 PM, Thierry Carrez > 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 >

Re: [Openstack] best practices for merging common into specific projects

On Wed, Jul 18, 2012 at 7:00 PM, Thierry Carrez 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). > >

Re: [Openstack] best practices for merging common into specific projects

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 >> t

Re: [Openstack] best practices for merging common into specific projects

On Wed, 2012-07-04 at 11:57 +0200, Thierry Carrez wrote: > Monty Taylor wrote: > > However, with a versioned library model, the projects can consume things > > pinned to specific versions, and then they can submit a change that > > updates the version depend and the code which needs to be updated t

Re: [Openstack] best practices for merging common into specific projects

On Tue, 2012-07-03 at 14:47 -0500, Andrew Bogott wrote: > Like most people in this thread, I too long for an end to the weird > double-commit process that we're using now. So I'm happy to set aside > my original Best Practices proposal until there's some consensus > regarding how much longer w

Re: [Openstack] best practices for merging common into specific projects

On Tue, 2012-07-03 at 18:59 +, Gabriel Hurley wrote: > The notion that copying code is any protection against APIs that may > change is a red herring. It's the exact same effect as pegging a > version of a dependency (whether it's a commit hash or a real version > number), except now you have c

Re: [Openstack] best practices for merging common into specific projects

(Sorry, was away for a couple of weeks) On Mon, 2012-07-02 at 15:26 -0400, Russell Bryant wrote: > On 07/02/2012 03:16 PM, Andrew Bogott wrote: > > Background: > > > > The openstack-common project is subject to a standard code-review > > process (and, soon, will also have Jenkins testing gate

Re: [Openstack] best practices for merging common into specific projects

t; Thierry Carrez > Sent: Wednesday, July 04, 2012 2:57 AM > To: openstack@lists.launchpad.net > Subject: Re: [Openstack] best practices for merging common into specific > projects > > Monty Taylor wrote: > > However, with a versioned library model, the projects can consume >

Re: [Openstack] best practices for merging common into specific projects

On Tue, Jul 3, 2012 at 2:59 PM, Gabriel Hurley wrote: > The notion that copying code is any protection against APIs that may > change is a red herring. It's the exact same effect as pegging a version of > a dependency (whether it's a commit hash or a real version number), except > now you have cod

Re: [Openstack] best practices for merging common into specific projects

On 07/03/2012 02:00 PM, Dan Prince wrote: I don't see this as much different as any other patches to nova (or whatever project is using common). It should be a proper patch series. If the person pulling it in doesn't understand the merge well enough to produce the patch series with proper co

Re: [Openstack] best practices for merging common into specific projects

-openstack-bounces+chrisfer=us.ibm@lists.launchpad.net wrote: - >To: openstack@lists.launchpad.net >From: Monty Taylor  [snip] >So honestly, I'd say the real key is getting us closer to the point >where openstack-common is a proper library, because all of the rest of >the complexity

Re: [Openstack] best practices for merging common into specific projects

On Tuesday, July 3, 2012 at 21:17 PM, Monty Taylor wrote: > Interestingly enough - gerrit supports submodules pretty well... and it > does exactly what Eric said below ... if both the project and > superproject are in gerrit, and a change is made to the project, gerrit > can automatically update th

Re: [Openstack] best practices for merging common into specific projects

- > From: openstack-bounces+gabriel.hurley=nebula@lists.launchpad.net > [mailto:openstack- > bounces+gabriel.hurley=nebula@lists.launchpad.net] On Behalf Of > Thierry Carrez > Sent: Wednesday, July 04, 2012 2:57 AM > To: openstack@lists.launchpad.net > Subject: Re: [

Re: [Openstack] best practices for merging common into specific projects

Monty Taylor wrote: > However, with a versioned library model, the projects can consume things > pinned to specific versions, and then they can submit a change that > updates the version depend and the code which needs to be updated to > support the version change, and that change can be atomic. >

Re: [Openstack] best practices for merging common into specific projects

lto:openstack-bounces+gabriel.hurley=nebula@lists.launchpad.net] > *On Behalf Of *Andrew Bogott > *Sent:* Tuesday, July 03, 2012 3:54 PM > *To:* Eric Windisch; openstack@lists.launchpad.net > *Subject:* Re: [Openstack] best practices for merging common into > specific project

Re: [Openstack] best practices for merging common into specific projects

I've been following along at home a bit. I can totally see where it's desirable to have well thought out APIs that you can commit to supporting and encourage other people to use. And that you sometimes have expedient code that you aren't as comfortable with. What I don't get is how using a

Re: [Openstack] best practices for merging common into specific projects

+gabriel.hurley=nebula@lists.launchpad.net] On Behalf Of Andrew Bogott Sent: Tuesday, July 03, 2012 3:54 PM To: Eric Windisch; openstack@lists.launchpad.net Subject: Re: [Openstack] best practices for merging common into specific projects On 7/3/12 5:47 PM, Eric Windisch wrote: git submodules don't

Re: [Openstack] best practices for merging common into specific projects

On 7/3/12 5:47 PM, Eric Windisch wrote: git submodules don't have to be linked to the head of a branch. Instead of double-commiting (for every commit), we can do a single commit in each project to change the git reference of the submodule. This would not be too far from the existing behavior, e

Re: [Openstack] best practices for merging common into specific projects

git submodules don't have to be linked to the head of a branch. Instead of double-commiting (for every commit), we can do a single commit in each project to change the git reference of the submodule. This would not be too far from the existing behavior, except that it would minimize the double c

Re: [Openstack] best practices for merging common into specific projects

Dan Prince writes: > If someone wants to split openstack-common changes into patchsets that > might be Okay in small numbers. If you are merging say 5-10 changes > from openstack common into all the various openstack projects that > could translate into a rather large number of reviews (25+) for

Re: [Openstack] best practices for merging common into specific projects

l.hurley=nebula@lists.launchpad.net] On Behalf Of > James E. Blair > Sent: Tuesday, July 03, 2012 6:56 AM > To: andrewbog...@gmail.com > Cc: openstack@lists.launchpad.net > Subject: Re: [Openstack] best practices for merging common into specific > projects > > Andrew Bogo

Re: [Openstack] best practices for merging common into specific projects

On 7/3/12 1:59 PM, Gabriel Hurley wrote: The notion that copying code is any protection against APIs that may change is a red herring. It's the exact same effect as pegging a version of a dependency (whether it's a commit hash or a real version number), except now you have code duplication. An

Re: [Openstack] best practices for merging common into specific projects

From: openstack-bounces+gabriel.hurley=nebula@lists.launchpad.net > [mailto:openstack- > bounces+gabriel.hurley=nebula@lists.launchpad.net] On Behalf Of > James E. Blair > Sent: Tuesday, July 03, 2012 6:56 AM > To: andrewbog...@gmail.com > Cc: openstack@lists.launchpad.net > Subje

Re: [Openstack] best practices for merging common into specific projects

- Original Message - > From: "Russell Bryant" > To: andrewbog...@gmail.com > Cc: "Andrew Bogott" , openstack@lists.launchpad.net > Sent: Monday, July 2, 2012 3:26:56 PM > Subject: Re: [Openstack] best practices for merging common into specific

Re: [Openstack] best practices for merging common into specific projects

I think that's a good little explanation as to why we have openstack-common, but when did it become a good reason to copy code around via an inclusion mechanism? Lots of code is in packages (outside of openstack, in pypi and elsewhere) that is also in 'incubation' (in fact, what code isn't in p

Re: [Openstack] best practices for merging common into specific projects

Andrew Bogott writes: > I. As soon as a patch drops into common, the patch author should > submit merge-from-common patches to all affected projects. > A. (This should really be done by a bot, but that's not going to > happen overnight) Actually, I think with our current level of tooli

Re: [Openstack] best practices for merging common into specific projects

On Jul 3, 2012, at 5:31 AM, Thierry Carrez wrote: > Gabriel Hurley wrote: >> On a more fundamental level, did I miss some tremendous reason why we have >> this "merge from common" pattern instead of making OpenStack Common a >> standard python dependency just like anything else? Especially wi

Re: [Openstack] best practices for merging common into specific projects

Thierry Carrez wrote: > Gabriel Hurley wrote: >> On a more fundamental level, did I miss some tremendous reason why we have >> this "merge from common" pattern instead of making OpenStack Common a >> standard python dependency just like anything else? Especially with the work >> Monty has recent

Re: [Openstack] best practices for merging common into specific projects

Gabriel Hurley wrote: > On a more fundamental level, did I miss some tremendous reason why we have > this "merge from common" pattern instead of making OpenStack Common a > standard python dependency just like anything else? Especially with the work > Monty has recently done on versioning and pa

Re: [Openstack] best practices for merging common into specific projects

: [Openstack] best practices for merging common into >specific projects > > > >Re: [Openstack] best practices for merging common into specific >projects > > >What about using openstack-common as a library instead of a >preprocessor ‘inclusion’ system/copy code ar

Re: [Openstack] best practices for merging common into specific projects

: [Openstack] best practices for merging common into specific projects What > about using openstack-common as a library instead of a preprocessor > ‘inclusion’ system/copy code around system?? > > Maybe its time for that to happen? > > It always seemed sort of silly to me t

Re: [Openstack] best practices for merging common into specific projects

On a more fundamental level, did I miss some tremendous reason why we have this "merge from common" pattern instead of making OpenStack Common a standard python dependency just like anything else? Especially with the work Monty has recently done on versioning and packaging the client libs from J

Re: [Openstack] best practices for merging common into specific projects

Maybe its time to break out of that incubation?? Seems like if most projects are depending on these config files for code copying that that break out has really already occurred, but it just hasn't been written down or made official? I don't quite understand how a project can be in incubation,

Re: [Openstack] best practices for merging common into specific projects

What about using openstack-common as a library instead of a preprocessor 'inclusion' system/copy code around system?? Maybe its time for that to happen? It always seemed sort of silly to me that files are being copied around to different projects like this, instead of referring to code in a

Re: [Openstack] best practices for merging common into specific projects

On 07/02/2012 03:16 PM, Andrew Bogott wrote: > Background: > > The openstack-common project is subject to a standard code-review > process (and, soon, will also have Jenkins testing gates.) Sadly, > patches that are merged into openstack-common are essentially orphans. > Bringing those chang