openstack-poc team mailing list archive
-
openstack-poc team
-
Mailing list archive
-
Message #00297
Re: [Openstack] proposal for policy around and management of client libraries
John Dickinson wrote:
>
> On Nov 8, 2011, at 10:54 AM, Thierry Carrez wrote:
>>
>> 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'm not ready to commit to one solution as better than the other yet. However, I don't see why a separate client library project managed by the same group as the core project needs to be seen as a proliferation of openstack core projects. "Nova" is still just one core project even if it has two components: the server-side engine and a client-facing library.
I could agree with you if solution (1) was chosen. If we follow solution
(2) though, it's not one core project with two components: it's two core
projects with the same team of developers. It's two separate projects in
GitHub, Gerrit, Jenkins and Launchpad. It's two separate release
processes. For everyone else involved, it's two separate core projects.
The PPB is consulted when a new core project is proposed to see if it's
ready and if its scope is within what we collectively define as
"OpenStack". I think it should be consulted when a new core project is
proposed (even if it shares the same team of developers) or if a given
project expands significantly its scope (to the point to have a new
release deliverable).
Just the fact that we disagree makes it relevant for a PPB discussion.
The decision affects more than just your project, so it's relevant. If
the PPB rules that the decision does not belong to it, then so be it,
but I see no reason to avoid the discussion altogether.
--
Thierry Carrez (ttx)
Release Manager, OpenStack
References