On Tue, Dec 8, 2015 at 9:54 PM, Guillermo Ontañón <guille...@midokura.com> wrote: > Hi Sandro, > > On Tue, Dec 8, 2015 at 7:31 AM, Sandro Mathys <san...@midokura.com> 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 (and much more so today > that it's an internal api), and even depends on it, all the tests/
do you mean that the rest api used between python-midonetclient and midonet-cluster is an internal api? > directory in midonet/ depends on python-midonetclient. A split would > make a lot of workflows costlier / inconvenient / impossible (for > instance, it becomes impossible to gate properly when a patch > introduces changes to the rest api). > >> There's two major reasons for >> this: >> >> 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. > > It is fairly common for a single source tarball to produce multiple > binary packages. In fact, midonet produces 4 binary packages, are you > proposing that we split out midonet-tools and midonet-cluster too? > > >> 2) When adding repositories to OpenStack, they need to be tagged. >> There's a bunch of tags, and one category is the "type": library [1] >> or service [2]. Now midonet is a service, but python-midonetclient is >> a library so they need to be separate repositories. > > I find it hard to buy this argument, the midonet repository includes > several other internal libraries and we are not splitting those out. > > Regards, > G > >> >> Thoughts? >> >> Cheers, >> Sandro >> >> [0] >> http://lists.openstack.org/pipermail/openstack-dev/2015-December/081216.html >> [1] http://governance.openstack.org/reference/tags/type_library.html >> [2] http://governance.openstack.org/reference/tags/type_service.html >> >> __________________________________________________________________________ >> OpenStack Development Mailing List (not for usage questions) >> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev