On Thu, Aug 28, 2014 at 12:22 PM, Richard Woo <richardwoo2...@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 <cor...@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@lists.openstack.org >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> > > > _______________________________________________ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > >
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev