+1 -- there is no point for commiting that review with external urls if those repos are to be created in stackforge.
P. On 03/19/2015 03:02 PM, Evgeniy L wrote: > Hi folks, > > I agree, lets create separate repo with its own cores and remove > fuel_development from fuel-web. > > But in this case I'm not sure if we should merge the patch which > has links to non-stackforge repositories, because location is going > to be changed soon. > > Also it will be cool to publish it on pypi. > > Thanks, > > On Thu, Mar 19, 2015 at 4:21 PM, Sebastian Kalinowski > <skalinow...@mirantis.com <mailto:skalinow...@mirantis.com>> wrote: > > As I wrote in the review already: I like the idea of merging > those two tools and making a separate repository. After that > we could make they more visible in our documentation and wiki > so they could benefit from being used by broader audience. > > Same for vagrant configuration - if it's useful (and it is > since newcomers are using them) we could at least move under > Mirantis organization on Github. > > Best, > Seabastian > > > 2015-03-19 13:49 GMT+01:00 Przemyslaw Kaminski > <pkamin...@mirantis.com <mailto:pkamin...@mirantis.com>>: > > Hello, > > Some time ago I wrote some small tools that make Fuel > development easier > and it was suggested to add info about them to the documentation -- > here's the review link [1]. > > Evgenyi Li correctly pointed out that we already have something like > fuel_development already in fuel-web. I think though that we > shouldn't > mix such stuff directly into fuel-web, I mean we recently > migrated CLI > to a separate repo to make fuel-web thinner. > > So a suggestion -- maybe make these tools more official and create > stackforge repos for them? I think dev ecosystem could benefit > by having > some standard way of dealing with the ISO (for example we get > questions > from people how to apply new openstack.yaml config to the DB). > > At the same time we could get rid of fuel_development and merge that > into the new repos (it has the useful 'revert' functionality that I > didn't think of :)) > > P. > > [1] https://review.openstack.org/#/c/140355/9/docs/develop/env.rst > > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: > openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > <http://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: > openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > <http://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
