> client We have separated launchpad project for client and we're publishing client releases to it.
> extra I'm neutral about moving job examples and API samples between sahara and extra > ui tests if we'll be able to remove sahara-dashboard before good integration tests for our pages will be done in horizon than we could move them to the extra repo as a temporary place, but sahara is the wrong place for ui test due to different layers. On Thu, May 29, 2014 at 5:59 PM, Trevor McKay <tmc...@redhat.com> wrote: > below, sahara-extra > > On Wed, 2014-05-28 at 20:02 +0400, Sergey Lukjanov wrote: >> Hey folks, >> >> it's a small wrap-up for the topic "Sahara subprojects releasing and >> versioning" that was discussed partially on summit and requires some >> more discussions. You can find details in [0]. >> >> > common >> >> We'll include only one tarball for sahara to the release launchpad >> pages. All other links will be provided in docs. >> >> > sahara-dashboard >> >> The merging to Horizon process is now in progress. We've decided that >> j1 is the deadline for merging main code parts and during the j2 all >> the code should be merged into Horizon, so, if in time of j2 we'll >> have some work on merging sahara-dashboard to Horizon not done we'll >> need to fallback to the separated sahara-dashboard repo release for >> Juno cycle and continue merging the code into the Horizon to be able >> to completely kill sahara-dashboard repo in K release. >> >> Where we should keep our UI integration tests? >> >> > sahara-image-elements >> >> We're agreed that some common parts should be merged into the >> diskimage-builder repo (like java support, ssh, etc.). The main issue >> of keeping -image-elements separated is how to release them and >> provide mapping sahara version - elements version. You can find >> different options in etherpad [0], I'll write here about the option >> that I think will work best for us. >> >> So, the idea is that sahara-image-elements is a bunch of scripts and >> tools for building images for Sahara. It's high coupled with plugins's >> code in Sahara, so, we need to align them good. Current default >> decision is to keep aligned versioning like 2014.1 and etc. It'll be >> discussed on the weekly irc team meeting May 29. >> >> > sahara-extra >> >> Keep it as is, no need to stop releasing, because we're not publishing >> anything to pypi. No real need for tags. > > Even if we keep the repo for now, I think we could simplify a little > bit. The edp-examples could be moved to the Sahara repo. Some of those > examples we use in the integration tests anyway -- why have them > duplicated? > >> >> >> > open questions >> >> If you have any objections for this model, please, share your thoughts >> before June 3 due to the Juno-1 (June 12) to have enough time to apply >> selected approach. >> >> [0] https://etherpad.openstack.org/p/juno-summit-sahara-relmngmt-backward >> >> Thanks. >> > > > > _______________________________________________ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Sincerely yours, Sergey Lukjanov Sahara Technical Lead (OpenStack Data Processing) Principal Software Engineer Mirantis Inc. _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
