On Tue, Nov 8, 2011 at 1:55 AM, Thierry Carrez <thie...@openstack.org>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). > I would prefer that #1 at least be considered an acceptable option, unless there's some major downside that hasn't occurred to me. Dan > > 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 ? > > 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. > > > 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. > > Regards, > > -- > Thierry Carrez (ttx) > Release Manager, OpenStack > > _______________________________________________ > Mailing list: https://launchpad.net/~openstack > Post to : openstack@lists.launchpad.net > Unsubscribe : https://launchpad.net/~openstack > More help : https://help.launchpad.net/ListHelp > -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~ Dan Wendlandt Sr. Product Manager Nicira Networks: www.nicira.com cell: 650-906-2650 twitter: danwendlant ~~~~~~~~~~~~~~~~~~~~~~~~~~~
_______________________________________________ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
