Joshua, I was talking about simple python sub-package inside existing repository, in existing package. I am suggesting to add muranoapi.engine.<name> sub-package, and nothing more.
On Mon, Mar 24, 2014 at 10:29 PM, Ruslan Kamaldinov < rkamaldi...@mirantis.com> wrote: > On Mon, Mar 24, 2014 at 10:08 PM, Joshua Harlow <harlo...@yahoo-inc.com> > wrote: > > Seeing that the following repos already exist, maybe there is some need > for > > cleanup? > > > > - https://github.com/stackforge/murano-agent > > - https://github.com/stackforge/murano-api > > - https://github.com/stackforge/murano-common > > - https://github.com/stackforge/murano-conductor > > - https://github.com/stackforge/murano-dashboard > > - https://github.com/stackforge/murano-deployment > > - https://github.com/stackforge/murano-docs > > - https://github.com/stackforge/murano-metadataclient > > - https://github.com/stackforge/murano-repository > > - https://github.com/stackforge/murano-tests > > ...(did I miss others?) > > > > Can we maybe not have more git repositories and instead figure out a way > to > > have 1 repository (perhaps with submodules?) ;-) > > > > It appears like murano is already exploding all over stackforge which > makes > > it hard to understand why yet another repo is needed. I understand why > from > > a code point of view, but it doesn't seem right from a code organization > > point of view to continue adding repos. It seems like murano > > (https://github.com/stackforge/murano) should just have 1 repo, with > > sub-repos (tests, docs, api, agent...) for its own organizational usage > > instead of X repos that expose others to murano's internal organizational > > details. > > > > -Josh > > > Joshua, > > I agree that this huge number of repositories is confusing for newcomers. > I've > spent some time to understand mission of each of these repos. That's why we > already did the cleanup :) [0] > > And I personally will do everything to prevent creation of new repo for > Murano. > > Here is the list of repositories targeted for the next Murano release (Apr > 17): > * murano-api > * murano-agent > * python-muranoclient > * murano-dashboard > * murano-docs > > The rest of these repos will be deprecated right after the release. Also > we > will rename murano-api to just "murano". murano-api will include all the > Murano services, functionaltests for Tempest, Devstack scripts, developer > docs. > I guess we already can update README files in deprecated repos to avoid > further > confusion. > > I wouldn't agree that there should be just one repo. Almost every OpenStack > project has it's own repo for python client. All the user docs are kept in > a > separate repo. Guest agent code should live in it's own repository to keep > number of dependencies as low as possible. I'd say there should be > required/comfortable minimum of repositories per project. > > > And one more nit correction: > OpenStack has it's own git repository [1]. We shoul avoid referring to > github > since it's just a convinient mirror, while [1] is an official > OpenStack repository. > > [0] > https://blueprints.launchpad.net/murano/+spec/repository-reorganization > [1] http://git.openstack.org/cgit/ > > > > Thanks, > Ruslan > > _______________________________________________ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > -- Serg Melikyan, Senior Software Engineer at Mirantis, Inc. http://mirantis.com | smelik...@mirantis.com +7 (495) 640-4904, 0261 +7 (903) 156-0836
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev