openstack team mailing list archive

[Thierry Carrez <thierry@xxxxxxxxxxxxx>]

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 ?

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