Just leave it as is. This whole thread is a waste of time.
On Dec 15, 2015 18:52, "Jaume Devesa" wrote:
> No. I'm saying that I prefer python-os-midonetclient to be a project by
> its own
> instead of being merged inside the neutron plugin repo.
>
> On 14 December 2015 at 18:43, Antoni Segura Pui
No. I'm saying that I prefer python-os-midonetclient to be a project by its
own
instead of being merged inside the neutron plugin repo.
On 14 December 2015 at 18:43, Antoni Segura Puimedon <
toni+openstac...@midokura.com> wrote:
>
>
> On Mon, Dec 14, 2015 at 6:07 PM, Jaume Devesa wrote:
>
>> +1
On Mon, Dec 14, 2015 at 6:07 PM, Jaume Devesa wrote:
> +1
>
> I think it is good compromise. Thanks Ryu!
>
> I understand the CLI will belong to the external part. I much prefer to
> have
> it in a separate project rather than into the plugin. Even if the code is
> tiny.
>
Let me summarize it:
+1
I think it is good compromise. Thanks Ryu!
I understand the CLI will belong to the external part. I much prefer to have
it in a separate project rather than into the plugin. Even if the code is
tiny.
If you will want to just do midonet calls for debugging or check the MidoNet
virtual infrastr
On Tue, Dec 15, 2015 at 1:00 AM, Sandro Mathys wrote:
> On Tue, Dec 15, 2015 at 12:02 AM, Ryu Ishimoto wrote:
>
> So if I understand you correctly, you suggest:
> 1) the (midonet/internal) low level API stays where it is and will
> still be called python-midonetclient.
> 2) the (neutron/external)
On Tue, Dec 15, 2015 at 12:02 AM, Ryu Ishimoto wrote:
> On Mon, Dec 14, 2015 at 6:34 PM, Sandro Mathys wrote:
>> On Thu, Dec 10, 2015 at 4:46 PM, Galo Navarro wrote:
>>>
>> Honestly, I don't think this discussion is leading anywhere.
>> Therefore, I'd like to request a decision by the MidoNet PT
On Mon, Dec 14, 2015 at 6:34 PM, Sandro Mathys wrote:
> On Thu, Dec 10, 2015 at 4:46 PM, Galo Navarro wrote:
>>
> Honestly, I don't think this discussion is leading anywhere.
> Therefore, I'd like to request a decision by the MidoNet PTL as per
> [1].
I apologize for jumping in a bit late. Clea
On Thu, Dec 10, 2015 at 4:46 PM, Galo Navarro wrote:
>
>
> On 10 December 2015 at 04:35, Sandro Mathys wrote:
>>
>> On Thu, Dec 10, 2015 at 12:48 AM, Galo Navarro wrote:
>> > Hi,
>> >
>> >> I think the goal of this split is well explained by Sandro in the first
>> >> mails of the chain:
>> >>
>>
On 10 December 2015 at 04:35, Sandro Mathys wrote:
> On Thu, Dec 10, 2015 at 12:48 AM, Galo Navarro wrote:
> > Hi,
> >
> >> I think the goal of this split is well explained by Sandro in the first
> >> mails of the chain:
> >>
> >> 1. Downstream packaging
> >> 2. Tagging the delivery properly as
On Thu, Dec 10, 2015 at 12:48 AM, Galo Navarro wrote:
> Hi,
>
>> I think the goal of this split is well explained by Sandro in the first
>> mails of the chain:
>>
>> 1. Downstream packaging
>> 2. Tagging the delivery properly as a library
>> 3. Adding as a project on pypi
>
> Not really, because (
On Tue, Dec 8, 2015 at 9:54 PM, Guillermo Ontañón
wrote:
> Hi Sandro,
>
> On Tue, Dec 8, 2015 at 7:31 AM, Sandro Mathys wrote:
>> Hi,
>>
>> As Takashi Yamamoto raised in another thread [0], python-midonetclient
>> should be split out into its own repo
>
>
> I'm strongly against on this one. Stuff
On Thu, Dec 10, 2015 at 12:48 AM, Galo Navarro wrote:
> Hi,
>
>> I think the goal of this split is well explained by Sandro in the first
>> mails of the chain:
>>
>> 1. Downstream packaging
>> 2. Tagging the delivery properly as a library
>> 3. Adding as a project on pypi
>
> Not really, because (
Hi,
> I think the goal of this split is well explained by Sandro in the first
> mails of the chain:
>
> 1. Downstream packaging
> 2. Tagging the delivery properly as a library
> 3. Adding as a project on pypi
Not really, because (1) and (2) are *a consequence* of the repo split. Not
a cause. Plea
2:48 PM
> Subject: Re: [openstack-dev] [midonet] Split up python-midonetclient
> To: "OpenStack Development Mailing List (not for usage questions)" <
> openstack-dev@lists.openstack.org>
> Cc: Jaume Devesa
>
>
> >> Ditto. We already have a mirror re
>> Ditto. We already have a mirror repo of pyc for this purpose
>> https://github.com/midonet/python-midonetclient, synced daily.
>
> Some of the problems with that is that it does not have any git log history
> nor does it feel like a coding project at all.
Of course, because the goal of this rep
On Wed, Dec 9, 2015 at 2:41 PM, Antoni Segura Puimedon <
toni+openstac...@midokura.com> wrote:
>
>
> On Tue, Dec 8, 2015 at 1:58 PM, Galo Navarro wrote:
>
>> Hi Sandro,
>>
>> >> 1) (Downstream) packaging: midonet and python-midonetclient are two
>> >> distinct packages, and therefore should have
On Tue, Dec 8, 2015 at 1:58 PM, Galo Navarro wrote:
> Hi Sandro,
>
> >> 1) (Downstream) packaging: midonet and python-midonetclient are two
> >> distinct packages, and therefore should have distinct upstream
> >> tarballs - which are compiled on a per repo basis.
>
> This is actually not accurate
Hi Sandro,
>> 1) (Downstream) packaging: midonet and python-midonetclient are two
>> distinct packages, and therefore should have distinct upstream
>> tarballs - which are compiled on a per repo basis.
This is actually not accurate: there is no such thing as a midonet
package. The midonet repo pr
Hi Sandro,
On Tue, Dec 8, 2015 at 7:31 AM, Sandro Mathys wrote:
> Hi,
>
> As Takashi Yamamoto raised in another thread [0], python-midonetclient
> should be split out into its own repo
I'm strongly against on this one. Stuff in the midonet/ repo is
developed in sync with python-midonetclient (a
On Tue, Dec 8, 2015 at 3:31 PM, Sandro Mathys wrote:
> Hi,
>
> As Takashi Yamamoto raised in another thread [0], python-midonetclient
> should be split out into its own repo. There's two major reasons for
> this:
>
> 1) (Downstream) packaging: midonet and python-midonetclient are two
> distinct pa
20 matches
Mail list logo
