What I can extract now from this thread is that Fuel should switch to testr because of the following reasons:
- Diversity of tools is a bad idea on a project scale - testrepository and related components are used in OpenStack Infra environment for much more tasks than just running tests - py.test won’t be added to global-requirements so there always be a chance of another dependency hell - Sticking to global requirements is an idea which is in the scope of discussions around Fuel. Sounds like that’s the point when we should just file appropriate bugs and use testr in smaller components, e. g., Fuel Client, first and then try in in Nailgun. - romcheg > 7 жовт. 2015 р. о 02:06 Monty Taylor <mord...@inaugust.com> написав(ла): > > On 10/06/2015 06:01 PM, Thomas Goirand wrote: >> On 10/06/2015 01:14 PM, Yuriy Taraday wrote: >>> On Mon, Oct 5, 2015 at 5:40 PM Roman Prykhodchenko <m...@romcheg.me >>> <mailto:m...@romcheg.me>> wrote: >>> >>> Atm I have the following pros. and cons. regarding testrepository: >>> >>> pros.: >>> >>> 1. It’s ”standard" in OpenStack so using it gives Fuel more karma >>> and moves it more under big tent >>> >>> >>> I don't think that big tent model aims at eliminating diversity of tools >>> we use in our projects. A collection of web frameworks used in big tent >>> is an example of that. >> >> From the downstream distro point of view, I don't agree in general, and >> with the web framework in particular. (though it's less a concern for >> the testr vs pbr). We keep adding dependencies and duplicates, but never >> remove them. For example, tablib and suds/sudsjurko need to be removed >> because they are not maintainable, there's not much work to do so, but >> nobody does the work... > > The Big Tent has absolutely no change in opinion about eliminating diversity > of tools. OpenStack has ALWAYS striven to reduce diversity of tools. Big Tent > applies OpenStack to more things that request to be part of OpenStack. > > Nothing has changed in the intent. > > Diversity of tools in a project this size is a bad idea. Always has been. > Always will be. > > The amount of web frameworks in use is a bug. > >>> 2. It’s in global requirements, so it doesn’t cause dependency hell >>> >>> That can be solved by adding py.test to openstack/requirements. > > No, it cannot. py.test/testr is not about dependency management. It's about a > much bigger picture of how OpenStack does development and how that > development can be managed. > >> I'd very much prefer if we could raise the barrier for getting a 3rd >> party new dependency in. I hope we can talk about this in Tokyo. That >> being said, indeed, adding py.test isn't so much of a problem, as it is >> widely used, already packaged, and maintained upstream. I'd still prefer >> if all projects were using the same testing framework and test runner >> though. > > As I said earlier in this thread, it has already been decided by the TC long > ago that we will use testr. Barring a (very unlikely) TC rescinding of that > decision, OpenStack projects use testr. There is zero value in expanding the > number of test runners. > > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org > <mailto:openstack-dev-requ...@lists.openstack.org>?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > <http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev>
signature.asc
Description: Message signed with OpenPGP using GPGMail
__________________________________________________________________________ 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
