On 2 June 2014 23:10, David Golden <x...@xdg.me> wrote: > On Mon, Jun 2, 2014 at 4:43 PM, demerphq <demer...@gmail.com> wrote: > > I don't understand your question. I am not asking that the tester debug > > anything, just that when my tests fail they send me the *verbose* failure > > output which contains valuable context on what failed which helps me > debug > > my code, just as I would like to see the *full* build output, and not > just > > the results from make test. > > While that's occasionally useful, it bloat the amount of data sent and > stored. The decision taken a while back is only to provide results > from the last phase to run.
On top of the point that this policy makes very little sense for an XS module, the fact is that the *build* step failed, yet cpantesters gave me *test* results. Sounds like the cpan tester framework is broken. Why did it run tests when the make step failed? And I have to say I really find that this policy undermines the utility of cpantesters for me. If a real user trys to install my software and it fails then they will typically on request provide me with details like the full build output. In this case I know I will be helping someone who actually needs my help. With cpantesters I have an automated build system that tells me my stuff is broken, but does not give me the details I need to fix it, and when I ask for them apparently it is too much bother for the person running the tests to actually supply what I asked. So they want me to do work to fix code that as far as I know is never going to actually be used on the platform they are testing, and they want me to do it in a way that is least convenient for me. I think that formula is pretty much bullshit. You need to fix your policies. Yves -- perl -Mre=debug -e "/just|another|perl|hacker/"
