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 e...@cloudscaling.com wrote:
The scope of common is expanding. I believe it is time to seriously
consider a proper PTL. Preferably, before the PTL elections.
+1
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,
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 in Nova,
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 monitor
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,
+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:
On Aug 2, 2012, at 1:05 PM, Eric Windisch e...@cloudscaling.com 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:
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*
+1
On Fri, Aug 3, 2012 at 6:47 AM, Vishvananda Ishaya vishvana...@gmail.comwrote:
On Aug 2, 2012, at 1:05 PM, Eric Windisch e...@cloudscaling.com wrote:
The scope of common is expanding. I believe it is time to seriously
consider a proper PTL. Preferably, before the PTL elections.
+1
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
On Thu, 2012-08-02 at 15:47 -0700, Vishvananda Ishaya wrote:
On Aug 2, 2012, at 1:05 PM, Eric Windisch e...@cloudscaling.com 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
On Wed, Jul 18, 2012 at 7:00 PM, Thierry Carrez thie...@openstack.orgwrote:
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
Doug Hellmann wrote:
On Wed, Jul 18, 2012 at 7:00 PM, Thierry Carrez thie...@openstack.org
mailto:thie...@openstack.org wrote:
Mark McLoughlin wrote:
Making our multiple projects converge onto consolidated and
well-accepted APIs is a bit painful work, but it is a
On Mon, Jul 23, 2012 at 12:00 PM, Thierry Carrez thie...@openstack.orgwrote:
Doug Hellmann wrote:
On Wed, Jul 18, 2012 at 7:00 PM, Thierry Carrez thie...@openstack.org
mailto:thie...@openstack.org wrote:
Mark McLoughlin wrote:
Making our multiple projects converge onto
(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 gates.)
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 code
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
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 to
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
-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 is
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
On Tue, Jul 3, 2012 at 2:59 PM, Gabriel Hurley gabriel.hur...@nebula.comwrote:
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),
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
things pinned to specific versions, and then they can
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.
So
: 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: [Openstack] best practices for merging
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 the
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
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 recently done on
On Jul 3, 2012, at 5:31 AM, Thierry Carrez thie...@openstack.org 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?
Andrew Bogott abog...@wikimedia.org 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
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
- Original Message -
From: Russell Bryant rbry...@redhat.com
To: andrewbog...@gmail.com
Cc: Andrew Bogott abog...@wikimedia.org, openstack@lists.launchpad.net
Sent: Monday, July 2, 2012 3:26:56 PM
Subject: Re: [Openstack] best practices for merging common into specific
@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
Subject: Re: [Openstack] best practices for merging common into specific
projects
: 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 Bogott abog...@wikimedia.org writes:
I. As soon as a patch drops into common, the patch author should
Dan Prince dpri...@redhat.com 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
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
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,
+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 have
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
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 have to be linked to the head of a branch. Instead
of double-commiting
Having spent some time last week writing code for openstack-common,
and having spent yet more time trying to get those changes into Nova, I
think it would be useful to define some best practices when crossing the
boundary between common and other openstack projects.
Background:
The
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 changes
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
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,
@lists.launchpad.net] On Behalf Of
Andrew Bogott
Sent: Monday, July 02, 2012 12:17 PM
To: openstack@lists.launchpad.net
Subject: [Openstack] best practices for merging common into specific
projects
Having spent some time last week writing code for openstack-common,
and having spent yet more time trying
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
Date: 07/02/2012 07:21PM
Subject: Re: [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 #8216;inclusion#8217; system/copy code around
47 matches
Mail list logo
