<br><br><div class="gmail_quote">On Tue, Nov 8, 2011 at 1:55 AM, Thierry Carrez <span dir="ltr"><<a href="mailto:thierry@openstack.org">thierry@openstack.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">

There are two ways of doing this.<br>
<br>
1. You can include the client code in the main core project, and produce<br>
two tarballs from it (one project, two release deliverables) much like<br>
what we'll need to do for Horizon (django module + ref impl).<br></blockquote><div><br></div><div>I would prefer that #1 at least be considered an acceptable option, unless there's some major downside that hasn't occurred to me.</div>

<div><br></div><div>Dan</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<br>
2. You can add the new client project as a separate core project, which<br>
happens to share the same PTL as its related project. This is more<br>
costly since it basically multiplies by 2 the number of projects to<br>
track (from a release management perspective).<br>
<br>
Which one are you after ?<br>
<div class="im"><br>
John Dickinson wrote:<br>
> 2) Why does the PPB need to vote? Actually, what would the PPB be voting on (assuming the answer to #1 is "no")?<br>
<br>
</div>The PPB is always consulted when adding new core projects. Whatever<br>
solution is chosen, you either create a new set of core projects<br>
(python-novaclient, for example, is currently a separate project), or<br>
you expand significantly the scope of existing core projects. That seems<br>
to warrant a PPB discussion.<br>
<br>
In all cases, this will result in expanding the core set of release<br>
deliverables, so expanding the scope of the project and spreading CI and<br>
release management resources thinner.<br>
<div class="im"><br>
> 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).<br>


<br>
</div>If we choose option 1 above, the client part would be a separate<br>
deliverable for the same project. Nova, for example, would produce two<br>
tarballs: nova and python-novaclient. They would obviously share the<br>
same schedule.<br>
<br>
If we choose option 2 above, aligning milestone dates would limit the<br>
increase in release management tracking work -- it might not be obvious<br>
for everyone, but having each project using separate dates does not make<br>
the release management job simpler.<br>
<br>
Regards,<br>
<font color="#888888"><br>
--<br>
Thierry Carrez (ttx)<br>
Release Manager, OpenStack<br>
</font><div><div></div><div class="h5"><br>
_______________________________________________<br>
Mailing list: <a href="https://launchpad.net/~openstack" target="_blank">https://launchpad.net/~openstack</a><br>
Post to     : <a href="mailto:openstack@lists.launchpad.net">openstack@lists.launchpad.net</a><br>
Unsubscribe : <a href="https://launchpad.net/~openstack" target="_blank">https://launchpad.net/~openstack</a><br>
More help   : <a href="https://help.launchpad.net/ListHelp" target="_blank">https://help.launchpad.net/ListHelp</a><br>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br>~~~~~~~~~~~~~~~~~~~~~~~~~~~<br>Dan Wendlandt <div>Sr. Product Manager <br>Nicira Networks: <a href="http://www.nicira.com" target="_blank">www.nicira.com</a><br>

cell: 650-906-2650<div>twitter: danwendlant<br>~~~~~~~~~~~~~~~~~~~~~~~~~~~<br></div></div><br>