openstack team mailing list archive

[Dan Wendlandt <dan@xxxxxxxxxx>]

On Tue, Nov 8, 2011 at 1:55 AM, Thierry Carrez <thierry@xxxxxxxxxxxxx>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@xxxxxxxxxxxxxxxxxxx
> 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
~~~~~~~~~~~~~~~~~~~~~~~~~~~