-dev] [Neutron] Simple proposal for stabilizing new
features in-tree
Hi,
I've been thinking a good bit on this on the right way to move forward with
this and in general the right way new services should be added. Yesterday I was
working on a bug that was causing some problems in the openstack
@lists.openstack.org
Subject: Re: [openstack-dev] [Neutron] Simple proposal for stabilizing new
features in-tree
Hi,
I've been thinking a good bit on this on the right way to move forward with
this and in general the right way new services should be added. Yesterday I was
working on a bug that was causing
.
From: Sridar Kandaswamy (skandasw) [skand...@cisco.com]
Sent: Thursday, August 14, 2014 10:12 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Neutron] Simple proposal for stabilizing new
features in-tree
Hi Wuhongning:
Yes u are correct
Hi,
I've been thinking a good bit on this on the right way to move forward with
this and in general the right way new services should be added. Yesterday I
was working on a bug that was causing some problems in the openstack infra.
We tracked down the issue then I uploaded a patch for it. A
gustavo panizzo (gfa) wrote:
only one think i didn't like it
why all url,api, etc has to include the word 'preview'?
i imagine that i would be consuming the new feature using heat, puppet,
local scripts, custom horizon, whatever. Why do you make me to change
all them when the feature moves
On 8/11/14, 4:52 AM, Thierry Carrez wrote:
gustavo panizzo (gfa) wrote:
only one think i didn't like it
why all url,api, etc has to include the word 'preview'?
i imagine that i would be consuming the new feature using heat, puppet,
local scripts, custom horizon, whatever. Why do you make me
On 8/8/14, 6:28 PM, Salvatore Orlando wrote:
If we want to keep everything the way it is, we have to change
everything [1]
This is pretty much how I felt after reading this proposal, and I felt
that this quote, which Ivar will probably appreciate, was apt to the
situation.
Recent events
[Note - I understand there are ongoing discussion that may lead to a
proposal for an out-of-tree incubation process for new Neutron features.
This is a complementary proposal that describes how our existing
development process can be used to stabilize new features in-tree over
the time frame
Hi Robert,
I think this is a great proposal.
Easy to understand and (at a first glance) easy to implement.
Also, it seems the perfect compromise for those who wanted GBP (as a
representative for this kind of extension) in tree, and those who wanted it
to be more mature first.
Fwiw, You have my
On Fri, Aug 8, 2014 at 1:21 PM, Robert Kukura kuk...@noironetworks.com wrote:
[Note - I understand there are ongoing discussion that may lead to a
proposal for an out-of-tree incubation process for new Neutron features.
This is a complementary proposal that describes how our existing
If we want to keep everything the way it is, we have to change everything
[1]
This is pretty much how I felt after reading this proposal, and I felt that
this quote, which Ivar will probably appreciate, was apt to the situation.
Recent events have spurred a discussion about the need for a change
Hi,
Robert Kukura's proposal does address the following:
1. Make it explicit to the user that an API is in preview until it's
moved out of the preview directories
2. One of the criteria to accept a BP for preview is for the functionality
to be optional via configuration. This will not impact the
i like your idea, as an operator, it gives me new features while keep my
core running fine.
only one think i didn't like it
why all url,api, etc has to include the word 'preview'?
i imagine that i would be consuming the new feature using heat, puppet,
local scripts, custom horizon, whatever. Why
13 matches
Mail list logo
