Re: [gentoo-dev] Re: Handling of tests (was: GCC USE flag changes)
On Wed, 1 May 2013 19:18:52 -0600 Ryan Hill dirtye...@gentoo.org wrote: On Wed, 1 May 2013 10:14:02 +0200 Ralph Sennhauser s...@gentoo.org wrote: On Tue, 30 Apr 2013 21:25:40 -0600 Ryan Hill dirtye...@gentoo.org wrote: I'm also going to rename the test flag to regression-test or something similar to get it out of FEATURES=test control. The testsuite is a huge time-suck and only useful to developers IMO (always expected to fail and primarily meant to be used to check for regressions between patchsets). I'm a big supporter of FEATURES=test by default and I think this is a small step towards that. This step is so tiny that we wont ever reach the goal like this. I was hoping it would set a precedent and then people would start thinking of splitting up test into categories, maybe even start a thread about it ;). Hehe, yes, you forced me to speak up with trying to set a precedent I think will get in the way of solving it in a more complete way. Though for that we have to agree on - split is desirable - which categories and how to classify tests - how to implement the splitting (EAPI support?) [...] ... and improve on how to configure Portage whether to run tests of any given category. Yeah I'd love to be able to do something like emerge TESTS=dev qa system -extradeps -expensive @world. I was thinking about a /etc/portage/package.test that works more like package.use. So most users will want to have something like: # package.test */* cheap Others might use: # package.test */* cheap normal */*::sunrise expensive my-pkg/foo * # broken test suite, bug XXX =dev-foo/bar-1.1 -* This would also be pretty similar to what your regression-tests useflag for gcc would have been. Even though Portage allows you to configure FEATURES=test on a per package basis since a couple years it doesn't seem to have become a common practice. While Portages mechanism is powerful it might be just to complex or tedious for the average user. As for your example command line 'emerge TESTS=dev qa system -extradeps -expensive @world', could you elaborate on what the categories dev qa system are about? signature.asc Description: PGP signature
[gentoo-dev] Re: Handling of tests (was: GCC USE flag changes)
On Wed, 1 May 2013 10:14:02 +0200 Ralph Sennhauser s...@gentoo.org wrote: On Tue, 30 Apr 2013 21:25:40 -0600 Ryan Hill dirtye...@gentoo.org wrote: I'm also going to rename the test flag to regression-test or something similar to get it out of FEATURES=test control. The testsuite is a huge time-suck and only useful to developers IMO (always expected to fail and primarily meant to be used to check for regressions between patchsets). I'm a big supporter of FEATURES=test by default and I think this is a small step towards that. This step is so tiny that we wont ever reach the goal like this. I was hoping it would set a precedent and then people would start thinking of splitting up test into categories, maybe even start a thread about it ;). Let's start to properly classify test into categories, like for instance - expected to be run (cheap, no silly deps) - good thing if run (still reasonable wrt resources) (current src_test) - if you are the maintainer or simply curious. (boost, jtreg and friends) Something like dev-test or qa-test? I can think of a couple packages.. ... and improve on how to configure Portage whether to run tests of any given category. Yeah I'd love to be able to do something like emerge TESTS=dev qa system -extradeps -expensive @world. -- gcc-porting toolchain, wxwidgets @ gentoo.org signature.asc Description: PGP signature
Re: [gentoo-dev] Re: Handling of tests (was: GCC USE flag changes)
2 other classes of tests you may want to consider : - network/internet accessibility required tests - markers for tests that are known/expected to fail under many conditions and are not worth end-user-testing, but end-users can force-running any way if they really want to see the individual failures. On 2 May 2013 13:18, Ryan Hill dirtye...@gentoo.org wrote: On Wed, 1 May 2013 10:14:02 +0200 Ralph Sennhauser s...@gentoo.org wrote: On Tue, 30 Apr 2013 21:25:40 -0600 Ryan Hill dirtye...@gentoo.org wrote: I'm also going to rename the test flag to regression-test or something similar to get it out of FEATURES=test control. The testsuite is a huge time-suck and only useful to developers IMO (always expected to fail and primarily meant to be used to check for regressions between patchsets). I'm a big supporter of FEATURES=test by default and I think this is a small step towards that. This step is so tiny that we wont ever reach the goal like this. I was hoping it would set a precedent and then people would start thinking of splitting up test into categories, maybe even start a thread about it ;). Let's start to properly classify test into categories, like for instance - expected to be run (cheap, no silly deps) - good thing if run (still reasonable wrt resources) (current src_test) - if you are the maintainer or simply curious. (boost, jtreg and friends) Something like dev-test or qa-test? I can think of a couple packages.. ... and improve on how to configure Portage whether to run tests of any given category. Yeah I'd love to be able to do something like emerge TESTS=dev qa system -extradeps -expensive @world. -- gcc-porting toolchain, wxwidgets @ gentoo.org -- Kent perl -e print substr( \edrgmaM SPA NOcomil.ic\\@tfrken\, \$_ * 3, 3 ) for ( 9,8,0,7,1,6,5,4,3,2 ); http://kent-fredric.fox.geek.nz
Re: [gentoo-dev] Re: Handling of tests (was: GCC USE flag changes)
On Wednesday 01 May 2013 21:24:07 Kent Fredric wrote: please do not top post -mike signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Re: Handling of tests (was: GCC USE flag changes)
On 2 May 2013 16:21, Mike Frysinger vap...@gentoo.org wrote: On Wednesday 01 May 2013 21:24:07 Kent Fredric wrote: please do not top post -mike My apologies, Gmail has forced upon us this new message composer, and it sucks, it actively discourages bottom posting, and I'm stuck with it. I even complained to them about it during their transition/experimentation/beta period, and they made it adequately clear to me they don't give a shit about technical users, especially not technical users who participate in lengthy mailing lists :( I do try, but basically, I have to mentally remember to work around its banal annoying changes for each message :( -- Kent
