<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Aug 28, 2014 at 12:22 PM, Richard Woo <span dir="ltr"><<a href="mailto:richardwoo2003@gmail.com" target="_blank">richardwoo2003@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr">I have another question about incubator proposal, for CLI and GUI. Do we imply that the incubator feature will need to branch python-neutron client, Horizon, and or Nova ( if changes are needed)?<div><br></div>
<div><br></div></div><div class=""><div class="h5"><div class="gmail_extra"><br></div></div></div></blockquote><div><br></div><div>This is as good a place for the docs perspective as any on this thread. </div><div><br></div><div>I think it's great to increase your dev velocity, but in the proposal I need to see a well-thought-out plan for when documentation should be on <a href="http://docs.openstack.org">docs.openstack.org</a> for deployers and users and when documentation should be in the API reference page at <a href="http://developer.openstack.org/api-ref.html">http://developer.openstack.org/api-ref.html</a>. A section addressing the timing and requirements would be sufficient.</div><div><br></div><div>The docs affected are: </div><div>CLI Reference <a href="http://docs.openstack.org/cli-reference/content/">http://docs.openstack.org/cli-reference/content/</a></div><div>Config Reference <a href="http://docs.openstack.org/icehouse/config-reference/content/">http://docs.openstack.org/icehouse/config-reference/content/</a></div><div>User Guide <a href="http://docs.openstack.org/user-guide/content/">http://docs.openstack.org/user-guide/content/</a></div><div>Admin User Guide <a href="http://docs.openstack.org/user-guide-admin/content/">http://docs.openstack.org/user-guide-admin/content/</a></div><div>Cloud Admin User Guide <a href="http://docs.openstack.org/admin-guide-cloud/content/">http://docs.openstack.org/admin-guide-cloud/content/</a></div><div>API Reference <a href="http://developer.openstack.org/api-ref.html">http://developer.openstack.org/api-ref.html</a></div><div><br></div><div>I won't argue that the Install Guide should be included as these items aren't exactly "happy path" quite yet.</div><div><br></div><div>Also in the wiki page, I see a line saying " link to commits in private trees is acceptable" -- is it really? How would readers get to it?<br><br>Thanks,<br>Anne</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div class=""><div class="h5"><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Aug 26, 2014 at 7:09 PM, James E. Blair <span dir="ltr"><<a href="mailto:corvus@inaugust.com" target="_blank">corvus@inaugust.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">Hi,<br>
<br>
After reading <a href="https://wiki.openstack.org/wiki/Network/Incubator" target="_blank">https://wiki.openstack.org/wiki/Network/Incubator</a> I have<br>
some thoughts about the proposed workflow.<br>
<br>
We have quite a bit of experience and some good tools around splitting<br>
code out of projects and into new projects. But we don't generally do a<br>
lot of importing code into projects. We've done this once, to my<br>
recollection, in a way that preserved history, and that was with the<br>
switch to keystone-lite.<br>
<br>
It wasn't easy; it's major git surgery and would require significant<br>
infra-team involvement any time we wanted to do it.<br>
<br>
However, reading the proposal, it occurred to me that it's pretty clear<br>
that we expect these tools to be able to operate outside of the Neutron<br>
project itself, to even be releasable on their own. Why not just stick<br>
with that? In other words, the goal of this process should be to create<br>
separate projects with their own development lifecycle that will<br>
continue indefinitely, rather than expecting the code itself to merge<br>
into the neutron repo.<br>
<br>
This has advantages in simplifying workflow and making it more<br>
consistent. Plus it builds on known integration mechanisms like APIs<br>
and python project versions.<br>
<br>
But more importantly, it helps scale the neutron project itself. I<br>
think that a focused neutron core upon which projects like these can<br>
build on in a reliable fashion would be ideal.<br>
<br>
-Jim<br>
<br>
_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</blockquote></div><br></div>
</div></div><br>_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br></blockquote></div><br></div></div>