Skip Menu |

This queue is for tickets about the Test-Broken CPAN distribution.

Report information
The Basics
Id: 110908
Status: resolved
Priority: 0/
Queue: Test-Broken

People
Owner: Nobody in particular
Requestors: SREZIC [...] cpan.org
Cc:
AdminCc:

Bug Information
Severity: (no value)
Broken in: 0.01
Fixed in: (no value)



Subject: Use a better namespace?
I think the module should use a different namespace. There are already existing modules just for the purpose of generating special reports, and your module could fit into one of these namespaces. Possible namespaces: - CPAN::Test::Dummy::Perl5::* - this one has a lot of modules just for testing different configuration setups (Makefile.PL and Build.PL), with or without dependencies, with circular dependencies, or testing fails like CPAN::Test::Dummy::Perl5::Make::FailConfigRequires. I think your module would fit as CPAN::Test::Dummy::Perl5::Make::CompilationFails or so - Acme::CPAN::Testers::* - a series of modules from BINGOS. There's already a Acme::CPAN::Testers::UNKNOWN, but this is for different kind of UNKNOWN reports, not for compilation failures. Again, your module could fit as Acme::CPAN::Testers::CompilationFailure or so - Devel::Fail::* - a smaller collection from MTHURN. Again, your module could fit as Devel::Fail::MakeCompile or so
Subject: Re: [rt.cpan.org #110908] Use a better namespace?
Date: Tue, 5 Jan 2016 20:22:23 +1100
To: <bug-Test-Broken [...] rt.cpan.org>
From: <sisyphus1 [...] optusnet.com.au>
Hi Slaven, I considered doing it under ACME but I thought maybe some smokers were being configured to avoid testing modules in that namespace. Is that incorrect ? If my concerns about that are unfounded then I think that your suggestion of Acme::CPAN::Testers::CompilationFailure is a good one - as, too, are your other suggestions. I don't mind what the module's name is, as long as it's not in a namespace that's likely to be excluded by cpantesters. So ... of the 3 alternatives you've provided, is there one that has an advantage over the others in terms of attracting broadest coverage from the testers ? Cheers, Rob Show quoted text
-----Original Message----- From: Slaven_Rezic via RT Sent: Tuesday, January 05, 2016 5:34 PM To: undisclosed-recipients: Subject: [rt.cpan.org #110908] Use a better namespace? Tue Jan 05 01:34:28 2016: Request 110908 was acted upon. Transaction: Ticket created by SREZIC Queue: Test-Broken Subject: Use a better namespace? Broken in: 0.01 Severity: (no value) Owner: Nobody Requestors: SREZIC@cpan.org Status: new Ticket <URL: https://rt.cpan.org/Ticket/Display.html?id=110908 > I think the module should use a different namespace. There are already existing modules just for the purpose of generating special reports, and your module could fit into one of these namespaces. Possible namespaces: - CPAN::Test::Dummy::Perl5::* - this one has a lot of modules just for testing different configuration setups (Makefile.PL and Build.PL), with or without dependencies, with circular dependencies, or testing fails like CPAN::Test::Dummy::Perl5::Make::FailConfigRequires. I think your module would fit as CPAN::Test::Dummy::Perl5::Make::CompilationFails or so - Acme::CPAN::Testers::* - a series of modules from BINGOS. There's already a Acme::CPAN::Testers::UNKNOWN, but this is for different kind of UNKNOWN reports, not for compilation failures. Again, your module could fit as Acme::CPAN::Testers::CompilationFailure or so - Devel::Fail::* - a smaller collection from MTHURN. Again, your module could fit as Devel::Fail::MakeCompile or so
RT-Send-CC: sisyphus1 [...] optusnet.com.au
On 2016-01-05 04:23:23, sisyphus1@optusnet.com.au wrote: Show quoted text
> Hi Slaven, > > I considered doing it under ACME but I thought maybe some smokers were > being > configured to avoid testing modules in that namespace. Is that > incorrect ?
Good point. It's possible that some smokers are configured to exclude all Acme::* modules (mine is not, but I don't know for others). Show quoted text
> If my concerns about that are unfounded then I think that your > suggestion of > Acme::CPAN::Testers::CompilationFailure is a good one - as, too, are > your > other suggestions. > > I don't mind what the module's name is, as long as it's not in a > namespace > that's likely to be excluded by cpantesters. > > So ... of the 3 alternatives you've provided, is there one that has an > advantage over the others in terms of attracting broadest coverage > from the > testers ?
Typical strategies to pick distributions for testing are: (1) test only recently uploaded stuff (2) test a fixed list of (important?) modules (3) test everything (4) don't run a smoker, but send reports while installing CPAN modules for real usage Based on this list there's no preference for any of these strategies. But whatever namespace you pick, you have probably to create regular dummy releases, so the smokers using the first strategy pick your module. Otherwise I would vote for the CPAN::Test::Dummy::Perl5::*, as there is already a lot of stuff here and your module could serve as another testcase for cpan installers & reporting modules. Regards, Slaven Show quoted text
> > Cheers, > Rob > > -----Original Message----- > From: Slaven_Rezic via RT > Sent: Tuesday, January 05, 2016 5:34 PM > To: undisclosed-recipients: > Subject: [rt.cpan.org #110908] Use a better namespace? > > Tue Jan 05 01:34:28 2016: Request 110908 was acted upon. > Transaction: Ticket created by SREZIC > Queue: Test-Broken > Subject: Use a better namespace? > Broken in: 0.01 > Severity: (no value) > Owner: Nobody > Requestors: SREZIC@cpan.org > Status: new > Ticket <URL: https://rt.cpan.org/Ticket/Display.html?id=110908 > > > > I think the module should use a different namespace. There are already > existing modules just for the purpose of generating special reports, > and > your module could fit into one of these namespaces. Possible > namespaces: > > - CPAN::Test::Dummy::Perl5::* - this one has a lot of modules just for > testing different configuration setups (Makefile.PL and Build.PL), > with or > without dependencies, with circular dependencies, or testing fails > like > CPAN::Test::Dummy::Perl5::Make::FailConfigRequires. I think your > module > would fit as CPAN::Test::Dummy::Perl5::Make::CompilationFails or so > > - Acme::CPAN::Testers::* - a series of modules from BINGOS. There's > already > a Acme::CPAN::Testers::UNKNOWN, but this is for different kind of > UNKNOWN > reports, not for compilation failures. Again, your module could fit as > Acme::CPAN::Testers::CompilationFailure or so > > - Devel::Fail::* - a smaller collection from MTHURN. Again, your > module > could fit as Devel::Fail::MakeCompile or so
RT-Send-CC: sisyphus1 [...] optusnet.com.au
Show quoted text
> Based on this list there's no preference for any of these strategies.
I meant "any of the proposed namespaces".
RT-Send-CC: sisyphus1 [...] optusnet.com.au
BTW, maybe you're interested in this open issue: https://rt.cpan.org/Ticket/Display.html?id=100467
Subject: Re: [rt.cpan.org #110908] Use a better namespace?
Date: Wed, 6 Jan 2016 22:41:39 +1100
To: <bug-Test-Broken [...] rt.cpan.org>
From: <sisyphus1 [...] optusnet.com.au>
Show quoted text
> BTW, maybe you're interested in this open issue: > https://rt.cpan.org/Ticket/Display.html?id=100467
Yes - Bingos had a NetBSD smoker that used to do just that - and I'm hoping to find out if it's fixed yet, and/or if there are other testers that are doing the same thing. I made repeated attempts (2 counts as "repeated" doesn't it ? ;-) to get Bingos to fix this, but didn't get any response. In the end, to avoid the 30 or so false FAIL reports generated by that smoker, I had to enhance the Makefile.PL to predetermine that libquadmath.h would not be found. (I should not have had to do that - which is my first beef.) And then, there's this predominating view that cpantester FAIL reports are infallible - and that there is therefore no need to even look at the reason for FAIL reports. How can people think like that, given my experience with that NetBSD smoker and Math::Float128 ? (And that's my second beef.) But maybe things are better now ... perhaps FAIL reports can *now* be taken as gospel. I wanted to create a module that would let me know if there are any cpantester reports that still misrepresent UNKNOWNs as FAILs - and hence I uploaded Test::Broken. You're right of course - I'll eventually re-release it as CPAN::Test::Dummy::Perl5::Make::CompilationFails, and send Test::Broken to backpan. (Is there other/additional action I should take re Test::Broken ?) And I'll also revert Math::Float128 to its original state of not pre-detecting the absence of libquadmath.h ... and see what happens to both Math::Float128 and CPAN::Test::Dummy::Perl5::Make::CompilationFails. Thanks Slaven. Cheers, Rob
RT-Send-CC: sisyphus1 [...] optusnet.com.au
On 2016-01-06 06:42:38, sisyphus1@optusnet.com.au wrote: Show quoted text
> > BTW, maybe you're interested in this open issue: > > https://rt.cpan.org/Ticket/Display.html?id=100467
> > Yes - Bingos had a NetBSD smoker that used to do just that - and I'm hoping > to find out if it's fixed yet, and/or if there are other testers that are > doing the same thing. > > I made repeated attempts (2 counts as "repeated" doesn't it ? ;-) to get > Bingos to fix this, but didn't get any response. > In the end, to avoid the 30 or so false FAIL reports generated by that > smoker, I had to enhance the Makefile.PL to predetermine that libquadmath.h > would not be found. (I should not have had to do that - which is my first > beef.) > > And then, there's this predominating view that cpantester FAIL reports are > infallible - and that there is therefore no need to even look at the reason > for FAIL reports. > How can people think like that, given my experience with that NetBSD smoker > and Math::Float128 ? (And that's my second beef.) > > But maybe things are better now ... perhaps FAIL reports can *now* be taken > as gospel. > I wanted to create a module that would let me know if there are any > cpantester reports that still misrepresent UNKNOWNs as FAILs - and hence I > uploaded Test::Broken. > > You're right of course - I'll eventually re-release it as > CPAN::Test::Dummy::Perl5::Make::CompilationFails, and send Test::Broken to > backpan. (Is there other/additional action I should take re Test::Broken ?) > > And I'll also revert Math::Float128 to its original state of not > pre-detecting the absence of libquadmath.h ... and see what happens to both > Math::Float128 and CPAN::Test::Dummy::Perl5::Make::CompilationFails. >
Thanks for releasing CPAN::Test::Dummy::Perl5::Make::CompilationFails.