From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (unknown [208.92.234.80]) by finch.gentoo.org (Postfix) with ESMTP id A51E81381FA for ; Tue, 27 May 2014 14:10:20 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 3416FE0941; Tue, 27 May 2014 14:09:50 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 284B9E0936 for ; Tue, 27 May 2014 14:09:49 +0000 (UTC) Received: from [192.168.1.130] (unknown [99.224.181.112]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: axs) by smtp.gentoo.org (Postfix) with ESMTPSA id 1640A33F874 for ; Tue, 27 May 2014 14:09:47 +0000 (UTC) Message-ID: <53849CA9.4090205@gentoo.org> Date: Tue, 27 May 2014 10:09:45 -0400 From: Ian Stakenvicius User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@lists.gentoo.org Reply-to: gentoo-dev@lists.gentoo.org MIME-Version: 1.0 To: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] RFC: Removing src_test from www-client/chromium References: <5384388D.9080701@gentoo.org> <20140527100528.5bf061bf@gentoo.org> In-Reply-To: <20140527100528.5bf061bf@gentoo.org> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Archives-Salt: adf7ce63-da1b-4bcd-b4f1-9e34571f21f2 X-Archives-Hash: 0df99139f4c63fe9de7cb8ee15073c78 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 27/05/14 04:05 AM, Tom Wijsman wrote: > On Tue, 27 May 2014 09:02:37 +0200 ""Paweł Hajdan, Jr."" > wrote: > >> I'm seriously considering just removing src_test to make the >> package more maintainable (less code, less bugs filed, can focus >> on things that *do* impact our users). >> >> If you decide to comment in favor of keeping src_test, please >> consider volunteering to help us with the bugs. >> >> Feel free to suggest solutions that fall somewhere in between - >> e.g. having src_test but not excluding any tests there and using >> RESTRICT=test, so that someone who really wants to run the tests >> FYI can do so. > > From a "test it for proper maintenance" point of view this makes > some sense; however, from a "test it for proper usability" point of > view this might become a bit questionable. Some users like to run > these tests in order to know their browser will work on their > system; perhaps even going further than that, it helps more users > report bugs upstream. > > You could ask the users to file the tests related bugs upstream. > I don't know how much chromium is built and tested on lesser-used arches (ie: arm, hppa, ia64, etc), but if there are dev's that try and maintain these keywords that aren't in the team, it might be a good idea to leave src_test in place, for them. However, you could always wrap the actual contents of src_test with an "if [[ -n ${I_KNOW_WHAT_IM_DOING} ]] " or similar to keep tests from running when the general userbase is trying to emerge it and happens to have FEATURES="test" globally enabled.. An ewarn telling users that if they really do want to run these tests, they can set the variable in make.conf or package.env or similar, and also specifying that the tests are skipped due to only being useful for upstream developers, may suffice... thoughts? -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iF4EAREIAAYFAlOEnKkACgkQ2ugaI38ACPCBswD8CAx2cK2UH+/IzysGPiQjOEzF n8Sxv3ZbtKh9+aBFv9IBAIMhfmgABYnUJlGUg/+mPHOY1d9XDRfM9WQskiJBc2Xk =nWr/ -----END PGP SIGNATURE-----