On 5/3/17 8:55 AM, Eric Fried wrote:
> Can you please point to the change(s) that move the constants? Or
> provide some other way to figure out which are affected?
>
This Hound search [1] provides an overall picture and can be honed to
specific projects as needed. The search will identify
Boden-
Can you please point to the change(s) that move the constants? Or
provide some other way to figure out which are affected?
Thanks,
Eric (efried)
On 05/03/2017 09:30 AM, Boden Russell wrote:
> If your project uses
On 24 November 2016 at 10:16, Neil Jerram wrote:
> To be clear, when I said 'catching such issues', what I meant was:
> 'letting me know promptly that I now need to update networking-calico'.
>
We're asking folks to take a number of steps to properly communicate
potential issues
To be clear, when I said 'catching such issues', what I meant was: 'letting
me know promptly that I now need to update networking-calico'.
I absolutely did not mean any kind of delaying or blocking a neutron or
neutron-lib change.
Thanks,
Neil
On Thu, Nov 24, 2016 at 5:43 PM Kevin Benton
On 24 November 2016 at 09:41, Kevin Benton wrote:
> Yeah, in this case I don't think it would have helped because it was
> removing several things from neutron simultaneously. The only thing that
> would have stopped that would have been jobs from all sub projects voting
> on
Yeah, in this case I don't think it would have helped because it was
removing several things from neutron simultaneously. The only thing that
would have stopped that would have been jobs from all sub projects voting
on each neutron change.
On Nov 24, 2016 10:02, "Armando M."
On 24 November 2016 at 05:27, Neil Jerram wrote:
> But I think a periodic check for a Neutron/neutron-lib-using project (such
> as networking-calico) would still be a decent way of catching such issues,
> wouldn't it?
>
It depends, and it would. There are many factors at play,
But I think a periodic check for a Neutron/neutron-lib-using project (such
as networking-calico) would still be a decent way of catching such issues,
wouldn't it?
On Thu, Nov 24, 2016 at 12:58 AM Kevin Benton wrote:
> The issue we had is different than breaking changes in
On 23 November 2016 at 16:42, Joshua Harlow wrote:
> A suggestion would also to setup something like the following:
>
> https://wiki.openstack.org/wiki/Oslo#Periodic
>
> Get the users of neutron lib being tested against the latest neutron lib
> (at least nightly) and
The issue we had is different than breaking changes in neutron-lib. The
issue we are running into now is bumps in the road when we are removing
deprecated things from Neutron that other projects are still using even
though they should be using the neutron-lib version instead.
On Wed, Nov 23, 2016
A suggestion would also to setup something like the following:
https://wiki.openstack.org/wiki/Oslo#Periodic
Get the users of neutron lib being tested against the latest neutron lib
(at least nightly) and seeing if they will be borked by a new neutron
lib merge...
I would encourage anyone working on neutron-lib related changes to have
a peek at the recently renovated contributing doc [1] if you haven't
already.
In particular the 'Phase 4: Consume' section [2] provides some tips on
how we see this workflow playing out.
Thanks
[1]
ev@lists.openstack.org>
> *Date: *Wednesday, November 16, 2016 at 6:16 PM
> *To: *OpenStack List <openstack-dev@lists.openstack.org>
> *Subject: *Re: [openstack-dev] [neutron] neutron-lib impact
>
>
>
>
>
>
>
> On 16 November 2016 at 00:55, Gary Kotton &
List <openstack-dev@lists.openstack.org>
Date: Wednesday, November 16, 2016 at 6:16 PM
To: OpenStack List <openstack-dev@lists.openstack.org>
Subject: Re: [openstack-dev] [neutron] neutron-lib impact
On 16 November 2016 at 00:55, Gary Kotton
<gkot...@vmware.com<mai
On 16 November 2016 at 00:55, Gary Kotton wrote:
> Hi,
>
> The directory integration will break all of the plugins and neutron
> projects. I do not think that this is something that we should do. It
> breaks the neutron API contract.
>
The plugin directory is an
Hi,
The directory integration will break all of the plugins and neutron projects. I
do not think that this is something that we should do. It breaks the neutron
API contract.
I think that we should only unblock the patch
https://review.openstack.org/#/c/386845. I think that due to the fact that
16 matches
Mail list logo