openstack team mailing list archive

[Thierry Carrez <thierry@xxxxxxxxxxxxx>]

Monty Taylor wrote:
> 
> 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.

Could you elaborate ? Keeping things in the same repo definitely helps
in keeping things in sync feature-wise... and also really helps if you
want to consider them subparts of existing core projects (see below).

> 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)

With solution (2), if you look at the issue from Gerrit, GitHub,
Launchpad or Jenkins, those will be separate projects though. The fact
that they share the same PTL is not enough to make them "one". For
example, they will have separate bug pages and release pages on
Launchpad, separate jobs on Jenkins...

Solution (1) actually allows you to have two tarballs as "release
deliverables" on the release page of a single core project. Solution (2)
doesn't.

In all cases you bring new client code projects into the realm of
"OpenStack core projects" (be it as an extension of scope of an existing
one or as a separate project), which I think warrants a discussion from
the PPB.

> 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.

Agreed. I'm just trying to make sure having them as separate projects
(solution (2) above) makes sense from a release management perspective.
Will they have their own set of blueprints, separate from their parent
project ? To me it sounds easier to derive two tarballs from a given
core project, rather than trying to consider a top-level project as some
kind of secondary project.

-- 
Thierry Carrez (ttx)
Release Manager, OpenStack