On 11/08/2011 01:55 AM, Thierry Carrez wrote: > There are two ways of doing this. > > 1. You can include the client code in the main core project, and produce > two tarballs from it (one project, two release deliverables) much like > what we'll need to do for Horizon (django module + ref impl). > > 2. You can add the new client project as a separate core project, which > happens to share the same PTL as its related project. This is more > costly since it basically multiplies by 2 the number of projects to > track (from a release management perspective). > > Which one are you after ?
Very strongly after (2). (1) will quickly become a disaster of armegeddon-like proportions. We're also working with horizon to split things back in to two projects. > John Dickinson wrote: >> 2) Why does the PPB need to vote? Actually, what would the PPB be voting on >> (assuming the answer to #1 is "no")? > > The PPB is always consulted when adding new core projects. Whatever > solution is chosen, you either create a new set of core projects > (python-novaclient, for example, is currently a separate project), or > you expand significantly the scope of existing core projects. That seems > to warrant a PPB discussion. > > In all cases, this will result in expanding the core set of release > deliverables, so expanding the scope of the project and spreading CI and > release management resources thinner. I think that we're actually proposing something slightly different - which is a core project (nova) which has more than one top-level repo managed by gerrit (nova, and python-novaclient) I don't mind managing extra things in CI/Gerrit - in fact, I would love it if we would pull in more things. I especially think that we HAVE to do this, since python-novaclient is a hard testing requirement for nova... so if we're not managing it the same way as we're managing our other projects, we're going to gate one set of code on another set of code which is ungated. >> 3) Why the requirement to have the same release schedule as the paired >> project? I would expect a client binding to change much less often than the >> underlying system (as I have seen with the Rackspace-specific swift >> bindings). > > If we choose option 1 above, the client part would be a separate > deliverable for the same project. Nova, for example, would produce two > tarballs: nova and python-novaclient. They would obviously share the > same schedule. > > If we choose option 2 above, aligning milestone dates would limit the > increase in release management tracking work -- it might not be obvious > for everyone, but having each project using separate dates does not make > the release management job simpler. Agree. _______________________________________________ Mailing list: https://launchpad.net/~openstack-poc Post to : openstack-poc@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack-poc More help : https://help.launchpad.net/ListHelp
