openstack-poc team mailing list archive

[Monty Taylor <mordred@xxxxxxxxxxxx>]

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.