Clarkb, As Robert said, you are missing the point.
I didn't say that "Rally wants this lib so it should be in global requirements". I asked only about python clients of stackforge projects that are regarding all rules: (Like py3k support, license, are in projects.txt and so on). From my point of view, if clients are regarding all reules there is no compatibility issues => it is easy to add them to g-r. Am I wrong? All, Sorry I wasn't able to be on meeting yesterday. First of all, we don't have any issues with having Murano/Mistral benchmarks and testing them in gates and supporting them in our tree. (We already have rally-dsvm-murano and rally-dsvm-mistral dsvm jobs that works well) The real issue is very bad user & dev experience caused by soft decencies. Let's take a look at actions of typical user (running Murano benchamrk): 1) Try to run tests for Murano 2) Input validation error: MuranoClient is missing please install it 3) WTF??? Let's take a look at actions of end developer (writing Murano benchmark): 1) Try to make new Murano benchmark 2) Need to import some exceptions from Murano client 3) All unit tests are failing.. 4) WTF??? Adding extra steps/conditions that are required for using product are adding exponential complexity to it. So having 5 such steps/conditions will make product inconsumable. So the only thing that I would like is to remove one "extra step" by adding good python clients to g-r. Best regards, Boris Pavlovic On Wed, Jan 21, 2015 at 4:15 AM, Robert Collins <robe...@robertcollins.net> wrote: > On 21 January 2015 at 10:21, Clark Boylan <cboy...@sapwetik.org> wrote: > ... > > This ml thread came up in the TC meeting today and I am responding here > > to catch the thread up with the meeting. The soft update option is the > > suggested fix for non openstack projects that want to have most of their > > requirements managed by global requirements. > > > > For the project structure reform opening things up we should consider > > loosening the criteria to get on the list and make it primarily based on > > technical criteria such as py3k support, license compatibility, upstream > > support/activity, and so on (basically the current criteria with less of > > a focus on where the project comes from if it is otherwise healthy). > > Then individual projects would choose the subset they need to depend on. > > This model should be viable with different domains as well if we go that > > route. > > > > The following is not from the TC meeting but addressing other portions > > of this conversation: > > > > At least one concern with this option is that as the number of total > > requirements goes up is the difficulty in debugging installation > > conflicts becomes more difficult too. I have suggested that we could > > write tools to help with this. Install bisection based on pip logs for > > example, but these tools are still theoretical so I may be > > overestimating their usefulness. > > > > To address the community scaling aspect I think you push a lot of work > > back on deployers/users if we don't curate requirements for anything > > that ends up tagged as "production ready" (or whatever the equivalent > > tag becomes). Essentially we are saying "this doesn't scale for us so > > now you deal with the fallout. Have fun", which isn't very friendly to > > people consuming the software. We already have an absurd number of > > requirements and management of them has appeared to scale. I don't > > foresee my workload going up if we open up the list as suggested. > > Perhaps I missed something, but the initial request wasn't about > random packages, it was about other stackforge clients - these are > things in the ecosystem! I'm glad we have technical solutions, but it > just seems odd to me that adding them would ever have been > controversial. > > On the pip solver side, joe gordon was working on a thing to install a > fixed set of packages by bypassing the pip resolver... not sure how > thats progressing. > > -Rob > > -- > Robert Collins <rbtcoll...@hp.com> > Distinguished Technologist > HP Converged Cloud > > __________________________________________________________________________ > 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
