Open Stack

On Thu, Aug 28, 2014 at 12:22 PM, Richard Woo <richardwoo2003 at gmail.com>
wrote:

> 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)?
>
>
>
>
This is as good a place for the docs perspective as any on this thread.

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
docs.openstack.org for deployers and users and when documentation should be
in the API reference page at http://developer.openstack.org/api-ref.html. A
section addressing the timing and requirements would be sufficient.

The docs affected are:
CLI Reference http://docs.openstack.org/cli-reference/content/
Config Reference
http://docs.openstack.org/icehouse/config-reference/content/
User Guide http://docs.openstack.org/user-guide/content/
Admin User Guide http://docs.openstack.org/user-guide-admin/content/
Cloud Admin User Guide http://docs.openstack.org/admin-guide-cloud/content/
API Reference http://developer.openstack.org/api-ref.html

I won't argue that the Install Guide should be included as these items
aren't exactly "happy path" quite yet.

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?

Thanks,
Anne


>
> On Tue, Aug 26, 2014 at 7:09 PM, James E. Blair <corvus at inaugust.com>
> wrote:
>
>> Hi,
>>
>> After reading https://wiki.openstack.org/wiki/Network/Incubator I have
>> some thoughts about the proposed workflow.
>>
>> We have quite a bit of experience and some good tools around splitting
>> code out of projects and into new projects.  But we don't generally do a
>> lot of importing code into projects.  We've done this once, to my
>> recollection, in a way that preserved history, and that was with the
>> switch to keystone-lite.
>>
>> It wasn't easy; it's major git surgery and would require significant
>> infra-team involvement any time we wanted to do it.
>>
>> However, reading the proposal, it occurred to me that it's pretty clear
>> that we expect these tools to be able to operate outside of the Neutron
>> project itself, to even be releasable on their own.  Why not just stick
>> with that?  In other words, the goal of this process should be to create
>> separate projects with their own development lifecycle that will
>> continue indefinitely, rather than expecting the code itself to merge
>> into the neutron repo.
>>
>> This has advantages in simplifying workflow and making it more
>> consistent.  Plus it builds on known integration mechanisms like APIs
>> and python project versions.
>>
>> But more importantly, it helps scale the neutron project itself.  I
>> think that a focused neutron core upon which projects like these can
>> build on in a reliable fashion would be ideal.
>>
>> -Jim
>>
>> _______________________________________________
>> OpenStack-dev mailing list
>> OpenStack-dev at lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140922/1828fc2b/attachment.html>