On Thu, Dec 10, 2015 at 12:48 AM, Galo Navarro <g...@midokura.com> 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 (1) and (2) are *a consequence* of the repo split. Not a > cause. Please correct me if I'm reading wrong but he's saying: > > - I want tarballs > - To produce tarballs, I want a separate repo, and separate repos have (1), > (2) as requirements. > > So this is where I'm going: producing a tarball of pyc does *not* require a > separate repo. If we don't need a new repo, we don't need to do all the > things that a separate repo requires.
in openstack, client libraries usually have a separate release schedules from servers. see "Final release for client libraries" in http://docs.openstack.org/releases/schedules/mitaka.html . in case we want to align to it, a single all-in-one repository doesn't sound viable to me. > > Now: > >> OpenStack provide us a tarballs web page[1] for each branch of each >> project >> of the infrastructure. >> Then, projects like Delorean can allow us to download theses tarball >> master >> branches, create the >> packages and host them in a target repository for each one of the rpm-like >> distributions[2]. I am pretty sure >> that there is something similar for Ubuntu. > > This looks more accurate: you're actually not asking for a tarball. You're > asking for being compatible with a system that produces tarballs off a repo. > This is very different :) > > So questions: we have a standalone mirror of the repo, that could be used > for this purpose. Say we move the mirror to OSt infra, would things work? > >> Everything is done in a very straightforward and standarized way, because >> every repo has its own >> deliverable. You can look how they are packaged and you won't see too many >> differences between >> them. Packaging a python-midonetclient it will be trivial if it is >> separated >> in a single repo. It will be > > But create a lot of other problems in development. With a very important > difference: the pain created by the mirror solution is solved cheaply with > software (e.g.: as you know, with a script). OTOH, the pain created by > splitting the repo is paid in very costly human resources. > >> complicated and we'll have to do tricky things if it is a directory inside >> the midonet repo. And I am not >> sure if Ubuntu and RDO community will allow us to have weird packaging >> metadata repos. > > I do get this point and it's a major concern, IMO we should split to a > different conversation as it's not related to where PYC lives, but to a more > general question: do we really need a repo per package? > > Like Guillermo and myself said before, the midonet repo generate 4 packages, > and this will grow. If having a package per repo is really a strong > requirement, there is *a lot* of work ahead, so we need to start talking > about this now. But like I said, it's orthogonal to the PYC points above. > > g > > > > __________________________________________________________________________ > 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