Mark McLoughlin wrote:
That actually goes to something I'm not aware of us - the project -
having spent much time discussing. We do twice yearly releases of our
collection of software, but there are public cloud providers which want
to essentially do continuous deployment from our development
On Fri, Jun 22, 2012 at 6:00 AM, Thierry Carrez thie...@openstack.org wrote:
Mark McLoughlin wrote:
That actually goes to something I'm not aware of us - the project -
having spent much time discussing. We do twice yearly releases of our
collection of software, but there are public cloud
How do these plans fit with the idea of creating a unified client library
(either as one package or several, based on a common core)?
On Mon, Jun 18, 2012 at 5:11 PM, Monty Taylor mord...@inaugust.com wrote:
We're trying to figure out how we release client libraries. We're really
close - but
On Mon, Jun 18, 2012 at 5:56 PM, Monty Taylor mord...@inaugust.com wrote:
On 06/18/2012 02:25 PM, Doug Hellmann wrote:
How do these plans fit with the idea of creating a unified client
library (either as one package or several, based on a common core)?
They are kind of orthogonal. At the
] On Behalf Of
Monty Taylor
Sent: Monday, June 18, 2012 3:00 PM
To: Joe Heck
Cc: openstack-poc@lists.launchpad.net; openst...@lists.launchpad.net
Subject: Re: [Openstack] [Openstack-poc] Thoughts on client library releasing
On 06/18/2012 02:26 PM, Joe Heck wrote:
Monty -
Thierry stated
On Tue, Jun 19, 2012 at 11:07:05AM -0700, Monty Taylor wrote:
I'm going to top-post, because there is a whole other thing which is not
a response to points below. Basically, this is yet-another-instance of
two competing and partially contradictory sets of use cases and usage
patterns that
Hey,
Does the PPB vote last night mean that the all-mighty PPB, in its
infinite wisdom, has decreed that nothing useful can come from further
discussion? :-)
I certainly hope not ...
On Tue, 2012-06-19 at 11:07 -0700, Monty Taylor wrote:
It is terrible for the public cloud implementations who
Hi Monty,
Thanks for sending.
For reference, this was the link you posted last week:
http://wiki.openstack.org/Governance/Proposed/LibraryProjectDefinition
One question I had on that is re:
the ability to release a client library outside of the core project
release cycle (requests have
Mark McLoughlin wrote:
One question I had on that is re:
the ability to release a client library outside of the core project
release cycle (requests have been coming in to our release manager for
this)
Who were these request from and why? That would help understand what
we're
On Tue, 2012-06-19 at 11:25 +0200, Thierry Carrez wrote:
Mark McLoughlin wrote:
One question I had on that is re:
the ability to release a client library outside of the core project
release cycle (requests have been coming in to our release manager for
this)
Who were these
Mark McLoughlin wrote:
Originally the client library projects were independent and were
released by their author to PyPI. People built their tooling and
automation
Interested in specific examples ...
Most developers apparently pull their libraries from PyPI. It's a bit
strange for people
On Tue, 2012-06-19 at 16:48 +0200, Thierry Carrez wrote:
Mark McLoughlin wrote:
[..]
However they also inherited the release scheme of the server project
(new version every 6 months), which was (or was not) synced to PyPI
depending of who was owning the PyPI project. More confusion as PyPI
We're trying to figure out how we release client libraries. We're really
close - but there are some sticking points.
First of all, things that don't really have dissent (with reasoning)
- We should release client libs to PyPI
Client libs are for use in other python things, so they should be
How do these plans fit with the idea of creating a unified client library
(either as one package or several, based on a common core)?
On Mon, Jun 18, 2012 at 5:11 PM, Monty Taylor mord...@inaugust.com wrote:
We're trying to figure out how we release client libraries. We're really
close - but
On Mon, 2012-06-18 at 17:25 -0400, Doug Hellmann wrote:
How do these plans fit with the idea of creating a unified client
library (either as one package or several, based on a common core)?
I am under the impression that there is not a desire, at present, to
create a unified client library.
On 06/18/2012 02:25 PM, Doug Hellmann wrote:
How do these plans fit with the idea of creating a unified client
library (either as one package or several, based on a common core)?
They are kind of orthogonal. At the point where python-openstackclient
is ready for release, we'd likely want to
16 matches
Mail list logo
