Re: Why make up a Makefile.PL (was: Re: git tarballs / tarfile comments)

[Thomas Klausner]

Hi!

On Wed, Sep 03, 2008 at 03:16:35PM -0400, David Golden wrote:

> There are handful of things on CPAN that are just zipped .pm files.  I

cpants says:
cpants=> select extension,count(*) from dist group by extension ;
 extension | count 
---+---
 tar.gz| 14762
 tgz   |   241
 zip   |   113

I've attachted the list, if this is of any help...

-- 
#!/usr/bin/perl  http://domm.plix.at
for(ref bless{},just'another'perl'hacker){s-:+-$"-g&&print$_.$/}
package
---
 Acme-POE-Knee-1.10.zip
 AI-NeuralNet-BackProp-0.89.zip
 AI-NeuralNet-Mesh-0.44.zip
 Algorithm-Line-Bresenham-C-0.1.zip
 Algorithm-Loops-1.031.zip
 Archive-Tyd-0.02.zip
 BitTorrent-V0.1.zip
 Chatbot-Alpha-2.04.zip
 Convert-MIL1750A-0.1.zip
 CPAN-Test-Dummy-Perl5-Make-Zip-1.03.zip
 Crypt-XXTEA-1.00.zip
 Data-Iterator-0.021.zip
 DBIx-Compare-1.0.zip
 DBIx-Compare-ContentChecksum-mysql-1.0.zip
 DBIx-Fun-0.02.zip
 Devel-TraceSubs-0.02.zip
 DISCO-0.01.zip
 EasyDate-103.zip
 ESplit1.00.zip
 extensible_report_generator_1.13.zip
 ExtUtils-FakeConfig-0.11.zip
 Finance-Bank-ES-Cajamadrid-0.04.zip
 Finance-Edgar-0.01.zip
 Games-LogicPuzzle-0.20.zip
 Games-Multiplayer-Manager-1.01.zip
 Graph-Maker-0.02.zip
 HTML-EasyTable-0.04.zip
 Inline-Octave-0.22.zip
 Joystick-1.01.zip
 LIMS-Controller-1.6b.zip
 LIMS-MT_Plate-1.17.zip
 Lingua-EN-Dict-0.20.zip
 Lingua-EN-VerbTense-3.00.zip
 link_NCBI.zip
 Memo32-1.01b.zip
 mGen-1.03.zip
 Microarray-0.45c.zip
 MIDI-Trans-0.15.zip
 modules/etext/etext.1.6.3.zip
 modules/SelfUnzip-0.01.zip
 modules/SOM-0.0601.zip
 Module-Versions-0.02.zip
 MRTG-Config-0.04.zip
 MSN-PersonalMessage-0.02.zip
 NCBI-0.10.zip
 NetIcecast-1.02.zip
 Net-IPAddress-1.10-PPM.zip
 Net-Server-POP3-0.0009.zip
 Notes/Notes.zip
 NPRG-0.31.zip
 Nums2Words-1.12.zip
 Object-Interface-1.1.zip
 os2/OS2-FTP-0_10.zip
 os2/OS2-UPM-0_10.zip
 os2/tk/Tk-OS2src-1.04.zip
 Parse-EventLog-0.7.zip
 ParseTemplate-0.37.zip
 PCX-Loader-0.50.zip
 Perl56/Win32-PerfMon.0.07-Perl5.6.zip
 Perl6-Interpolators-0.03.zip
 perlipse/Perlipse-0.02.zip
 Prima-prigraph-win32-1.06.zip
 Reduziguais.zip
 Regex-Number-GtLt-0.1.zip
 resched-0.7.2.zip
 rms.zip
 smg.zip
 System-Index-0.1.zip
 SystemTray-Applet-0.02.zip
 SystemTray-Applet-Win32-0.01.zip
 Template-Ast-0.02.zip
 Term-Getch-0.20.zip
 Term-Sample-0.25.zip
 Test-Version-0.02.zip
 Tie-Tk-Text-0.91.zip
 TimeConvert0.5.zip
 tinyperl-1.0-580-win32.zip
 Tk-DiffText-0.19.zip
 Tk-TOTD-0.20.zip
 Tkx-FindBar-0.06.zip
 UDPServersAndClients.zip
 VCS-StarTeam-0.08.zip
 VMS-Device-0_09.zip
 VMS-FlatFile-0.01.zip
 VMS-Queue-0_58.zip
 vms-user-0_02.zip
 Win32-ActAcc-1.1.zip
 Win32-Capture-1.1.zip
 Win32-Encode-0.5beta.zip
 Win32-Env-Path-0.01.zip
 win32-guidgen-0.04.zip
 Win32-GUI-Scintilla-1.7.zip
 Win32-HostExplorer-01.zip
 Win32-MCI-Basic-0.02.zip
 Win32-MediaPlayer-0.2.zip
 Win32-MIDI-0_2.zip
 Win32-MMF-0.09e.zip
 Win32-MultiMedia-0.01.zip
 Win32-OLE-CrystalRuntime-Application-0.08.zip
 Win32-OLE-OPC-0.92.zip
 Win32-PerlExe-Env-0.04.zip
 Win32-Printer-0.9.1.zip
 Win32-ShellExt-0.1.zip
 Win32/SimpleProcess/SimpleProcess_1.0.zip
 Win32-SqlServer-2.004.zip
 Win32-SystemInfo-0.11.zip
 Win32-TaskScheduler2.0.3.zip
 Win32-TieRegistry-0.25.zip
 Win32-TSA-Notify-0.01.zip
 WordPress-V1.zip
 WWW-MySpaceBot-0.01.zip
 WWW-PDAScraper-0.1.zip
 WWW-TwentyQuestions-0.01.zip
(113 rows)

Re: imaginary Makefile.PL

[Andreas J. Koenig]

> On Wed, 3 Sep 2008 10:57:20 -0700, Eric Wilhelm <[EMAIL PROTECTED]> said:

 >> And IMO this hints at a real problem that was mentioned
 >> in this thread, but was not really indicted: namely CPAN.pm’s
 >> logic that if there is no Makefile.PL, it is a sane idea to make
 >> one up out of whole cloth. I can’t believe anyone would think
 >> this could ever *ever* work, though Andreas does not strike me as
 >> the type to put harebrained heuristical magic in code. So I have
 >> to wonder what the justification for this behaviour might be. Is
 >> it really necessary or even helpful?

  > I've been told that it is intended for tarballs made in the times when 
  > there was no such thing as Makefile.PL yet.  Ah, history...

Not quite. The Makefile.PL was invented long before CPAN evolved. But
many early uploaders believed that uploading Foobar.pm is the way to
go. Or foobar.pl. And when you ask the CPAN shell to install
ANDK/keepcool-0.344 you'll probably be surprised that this *script*
installs just fine.

  % head /home/ftp/pub/PAUSE/authors/id/A/AN/ANDK/keepcool-0.344 
  #!/usr/bin/perl -w

  =head1 NAME

  keepcool - throttle a process with STOP und CONT calls

And if you read $CPAN/scripts/index.html you might imagine that the
mechanism had its merits. I'm not opposed to giving it up, just
providing the historical context.

  > Incidentally, I would love to be able to move forward to the time when 
  > there is neither Build.PL nor Makefile.PL.

Hear, hear! :-)


-- 
andreas

Re: Ignoring Non-Failures

[Dave Rolsky]

On Wed, 3 Sep 2008, David E. Wheeler wrote:


http://cpantesters.perl.org/author/DWHEELER.rss

This makes it easy for me to sift through things. The only thing that would 
make it better is if I could get it to display only FAILs. To whom should a 
feature request be sent (I thought I sent a patch to acme at one time…)?




I just wrote a comment on use Perl in dagolden's journal with the exact 
same request.


This would be fantastically more useful to me than the existing feed, 
which is usually 20-80 entries at a time, of which maybe 0-4 are of 
interest.



-dave

/*==
VegGuide.Org
Your guide to all that's veg
==*/

Re: Ignoring Non-Failures

[David E. Wheeler]

On Sep 3, 2008, at 11:22, Ricardo SIGNES wrote:


* "David E. Wheeler" <[EMAIL PROTECTED]> [2008-09-03T13:27:08]

 http://cpantesters.perl.org/author/DWHEELER.rss


Now that there's a new maintainer, I should send another email...


Say what? Sorry, I don't follow you here. Is there a new maintainer  
for cpantesters.perl.org I should mail?


Best,

David

Re: The relation between CPAN Testers and quality (or why CPAN Testers sucks if you don't need it)

[Andrew Moore]

On Wed, Sep 3, 2008 at 4:09 PM, David Golden <[EMAIL PROTECTED]> wrote:
> I'm interested in feedback on these ideas -- on list or off.  In
> particular, I'm now convinced that the "success" of CPAN Testers now
> prompts the need to move PL/make fails to UNKNOWN and to discontinue
> copying authors by individual testers.  I'm open to counter-arguments,
> but they'll need to convince me of a better long-run solution to the
> problems I identified.

David,

These two steps sound like they would go a long way toward making this
stuff less annoying for some, and just as useful for the rest.

I also think It's a good stop-gap measure to quiet the crowd while
improvements are coming.

Thanks!
-Andy

Re: Why make up a Makefile.PL (was: Re: git tarballs / tarfile comments)

[David Golden]

On Wed, Sep 3, 2008 at 3:55 PM, Aristotle Pagaltzis <[EMAIL PROTECTED]> wrote:
>> * BinTree
>> * Counter
>
> Can't even find those.
>
>> * Apache::AuthenIMAP
>
> Last update: 2002.

They may not be indexed on search.cpan.org, but they exist in
the02packages.details.txt.gz file and they exist in actual CPAN
mirrors. E.g.:

http://cpan.hexten.net/authors/id/T/TO/TOMC/scripts/CS-Talk/source/dstructs/trees/BinTree.pm.gz

If you load the CPAN shell and type "test BinTree" you'll see what happens.

Note -- you have to disable CPAN::SQLite if you have it as it can't
handle these kinds of files.  The native CPAN indexing will find them,
however.

Apache-AuthenIMAP-0.03 is unauthorized and isn't indexed in
02packages.  Someone requesting the "Apache::AuthenIMAP" module will
get the zipped pm file.

-- David

The relation between CPAN Testers and quality (or why CPAN Testers sucks if you don't need it)

[David Golden]

Yes, another CPAN Testers post on perl-qa.  Sorry, Andy.

I want to sum up a few things that I took away from the mega-threads
yesterday and propose a series of major changes to CPAN Testers.
Special thanks to an off-list (and very civil) conversation with
chromatic for triggering these thoughts.

__Type I and Type II errors__

In statistics, a Type I error means a "false positive" or "false
alarm".  For CPAN Testers, that's a bogus FAIL report.  A Type II
error means a "false negative", e.g. a bogus PASS report.  Often,
there is a trade-off between these.  If you think about spam filtering
as an example, reducing the chance of spam getting through the filter
(false negatives) tends to increase the odds that legitimate mail gets
flagged as spam (false positives).

Generally, those involved in CPAN Testers have taken the view that
it's better to have a false positives (false alarms) than false
negatives (a bogus PASS report).  Moreover, we've tended to believe --
without any real analysis -- that the false positive *ratio* (false
FAILs divided by all FAILs) is low.

But I've never heard a single complaint about a bogus PASS report and
I hear a lot of complaints about bogus FAILS, so it's reasonable to
think that we've got the tradeoff wrong. Moreover, I think the
downside to false positives is actually higher than for false
negatives if we believe that CPAN Testers is primarily a tool to help
authors improve quality rather than a tool to give users a guarantee
about how distributions work on any given platform.

__False positive ratios by author__

Even if the aggregate false positive ratio is low, individual CPAN
authors can experience extraordinarily high false positive ratios.
What I suddenly realized is that the higher the quality of an author's
distributions, the higher the false positive ratio.

Consider a "low quality" author -- one who is prone to portability
errors, missing dependencies and so on.  Most of the FAIL reports are
legitimate problems with the distribution.

Now consider a "high quality" author -- one who is careful to write
portable code, well-specified dependencies and so on.  For this
author, most of the FAIL reports only come when a tester has a broken
or misconfigured toolchain  The false positive ratio will approach
100%.

In other words, the *reward* that CPAN Testers has for high quality is
increased annoyance from false FAIL reports with little benefit.

__Repetition is desensitizing__

>From a statistical perspective, having lots of CPAN Testers reports
for a distribution even on a common platform helps improve confidence
in the aggregate result.  Put differently, it helps weed out "outlier"
reports from a tester who happens to have a broken toolchain.

However, from author's perspective, if a report is legitimate (and
assuming they care), they really only need to hear it once.  Having
more and more testers sending the same FAIL report on platform X is
overkill and gives yet more encouragement for authors to tune out.

So the more successful CPAN Testers is in attracting new testers, the
more duplicate FAIL reports authors are likely to receive, which makes
them less likely to pay attention to them.

__When is a FAIL not a FAIL?__

There are legitimate reasons that distributions could be broken such
that they fail during PL or make in ways that are not the fault of the
tester's toolchain, so it still seems like valuable information to
know when distributions can't build as well as when they don't pass
tests.  So we should report on this and not just skip reporting.  On
the other hand, most of the false positives that provoke complaint are
toolchain issues during PL or make/Build.

Right now there is no easy way to distinguish the phase of a FAIL
report from the subject of an email.  Removing PL and make/Build
failures from the FAIL category would immediately eliminate a major
source of false positives in the FAIL category and decrease the
aggregate false positive ratio in the FAIL category.  Though, as I've
shown, while this may decrease the incidence of false positives for
high quality authors, the false positive ratio is likely to remain
high.

It almost doesn't matter whether we reclassify these as UNKNOWN or
invent new grades.  Either way partitions the FAIL space in a way that
makes it easier for authors to focus on which ever part of the
PL/make/test cycle they care about.

__What we can fix now and what we can't__

Some of these issues can be addressed fairly quickly.

First, we can lower our collective tolerance of false positives -- for
example, stop telling authors to just ignore bogus reports if they
don't like it and find ways to filter them.  We have several places to
do this -- just in the last day we've confirmed that the latest
CPANPLUS dev version doesn't generate Makefile.PL's and some testers
have upgraded.  BinGOs has just put out CPANPLUS::YACSmoke 0.04 that
filters out these cases anyway if testers aren't on the bleeding edge
of CPANPLUS.  We now need to 

Re: imaginary Makefile.PL (and scripts)

[Eric Wilhelm]

# from Andreas J. Koenig
# on Wednesday 03 September 2008 13:11:

>And when you ask the CPAN shell to install
>ANDK/keepcool-0.344 you'll probably be surprised that this *script*
>installs just fine.
>
>  % head /home/ftp/pub/PAUSE/authors/id/A/AN/ANDK/keepcool-0.344
>  #!/usr/bin/perl -w
>
>  =head1 NAME
>
>  keepcool - throttle a process with STOP und CONT calls
>
>And if you read $CPAN/scripts/index.html you might imagine that the
>mechanism had its merits. I'm not opposed to giving it up, just
>providing the historical context.

That is different than a tarball though.  Does the script installation 
have to be given up in order to eliminate the ambiguous behavior in the 
case of a dist tarball?

On another note about scripts:  sleepserver still never made it into the 
index despite my reading of mldistwatch and working to try to get the 
META.yml 'provides' field right.  Is there something that says I have 
to have a .pm file to get indexed?

That is, this distribution is:

  bin/sleepserver
  META.yml
  Build.PL
  t/00-load.t

Which means that it can have dependencies and tests.

>> Incidentally, I would love to be able to move forward to the time
>> when there is neither Build.PL nor Makefile.PL.

> Hear, hear! :-)

Is 'dynamic_config: 0' supported?  The Build.PL in the above distro is 
not really needed.

--Eric
-- 
Peer's Law: The solution to the problem changes the problem.
---
http://scratchcomputing.com
---

Re: Why make up a Makefile.PL (was: Re: git tarballs / tarfile comments)

[Aristotle Pagaltzis]

* David Golden <[EMAIL PROTECTED]> [2008-09-03 21:20]:
> Examples:
> 
> * BinTree
> * Counter

Can’t even find those.

> * Apache::AuthenIMAP

Last update: 2002.

> Just to be on the safe side, however, earlier today I committed
> a patch to the CPAN trunk to bypass CPAN::Reporter entirely if
> a Makefile.PL has been generated by CPAN.pm.

Sounds good. Presumably those distros are all so old that their
authors are unlikely to have an interest in test reports
generated almost a decade after release.

Regards,
-- 
Aristotle Pagaltzis // 

Why make up a Makefile.PL (was: Re: git tarballs / tarfile comments)

[David Golden]

On Wed, Sep 3, 2008 at 1:38 PM, Aristotle Pagaltzis <[EMAIL PROTECTED]> wrote:
> But the FAIL did fail to point out the true source of the
> problem. And IMO this hints at a real problem that was mentioned
> in this thread, but was not really indicted: namely CPAN.pm's
> logic that if there is no Makefile.PL, it is a sane idea to make
> one up out of whole cloth. I can't believe anyone would think
> this could ever *ever* work, though Andreas does not strike me as
> the type to put harebrained heuristical magic in code. So I have
> to wonder what the justification for this behaviour might be. Is
> it really necessary or even helpful?

There are handful of things on CPAN that are just zipped .pm files.  I
think the generated Makefile.PL was intended to deal with them.

Examples:

* BinTree
* Counter
* Apache::AuthenIMAP

However, CPAN.pm only generates a Makefile.PL as a last resort (i.e.
no Build.PL and no Makefile.PL).

Just to be on the safe side, however, earlier today I committed a
patch to the CPAN trunk to bypass CPAN::Reporter entirely if a
Makefile.PL has been generated by CPAN.pm.

David

Re: imaginary Makefile.PL

[Aristotle Pagaltzis]

* Eric Wilhelm <[EMAIL PROTECTED]> [2008-09-03 20:00]:
> I've been told that it is intended for tarballs made in the
> times when there was no such thing as Makefile.PL yet.

The cure seems worse than the disease at this point in time then.

Maybe the heuristic in CPAN.pm could be just a little more
robust? I’m not sure what that would entail, of course; what
*did* distributions of the time look like? There have to be more
cues in there than *just* the absence of a Makefile.PL, I hope?

Regards,
-- 
Aristotle Pagaltzis // 

Re: qa: you're doing it wrong

[chromatic]

On Wednesday 03 September 2008 10:38:16 Eric Wilhelm wrote:

> If I see two reports about canned beets, I'm likely to just give up.
>
> So, we all agree that testing is good, but please... test the *code*?
>
> "The old version of the installer is broken"?  So what?

The question is whether CPAN Testers tests if a user can *install* a 
distribution on a given machine, or whether it tests if *tests pass* on a 
given machine.

From the second draft of the CPAN Testers FAQ:

If you get a fatal error during the build 
process (C or  C) you should grade the 
distribution as "fail", too. The only failures that should not be 
reported with B are those resulting from unfulfilled dependencies. 
Some modules require that other modules be installed in order to 
function. Some modules require that you have certain software on your 
system - the DBD modules are the clearest example of this. If DBD::MySQL 
fails because you don't have MySQL installed, that's not the module's 
fault.

Actually, that depends on I it fails. If it complains during C that a dependency is unfulfilled, then the module 
distribution is behaving properly. You should not report any result. 
*** Your system does not meet the requirements that the module distribution 
laid out, and is therefore not a valid testing platform right now. *** You 
may choose to satisfy the dependency by installing whatever the module 
asked for. If you do that, start the installation over.

(emphasis mine)
-- http://www.nntp.perl.org/group/perl.cpan.testers/2002/07/msg46794.html

I'm not going to hold anyone in particular to the draft of a FAQ written six 
years ago, but I've operated under the assumption that this was still the 
goal of CPAN Testers.

Sadly, beetometer++.

-- c

Re: Ignoring Non-Failures

[Ricardo SIGNES]

* "David E. Wheeler" <[EMAIL PROTECTED]> [2008-09-03T13:27:08]
>   http://cpantesters.perl.org/author/DWHEELER.rss

Now that there's a new maintainer, I should send another email... this file,
for me is so large (6,680,062 bytes) that my RSS reader times out trying to
retrieve it.

Ugh.

-- 
rjbs

Re: imaginary Makefile.PL

[Eric Wilhelm]

# from Aristotle Pagaltzis
# on Wednesday 03 September 2008 10:38:

>But the FAIL did fail to point out the true source of the
>problem. And IMO this hints at a real problem that was mentioned
>in this thread, but was not really indicted: namely CPAN.pm’s
>logic that if there is no Makefile.PL, it is a sane idea to make
>one up out of whole cloth. I can’t believe anyone would think
>this could ever *ever* work, though Andreas does not strike me as
>the type to put harebrained heuristical magic in code. So I have
>to wonder what the justification for this behaviour might be. Is
>it really necessary or even helpful?

I've been told that it is intended for tarballs made in the times when 
there was no such thing as Makefile.PL yet.  Ah, history...

Incidentally, I would love to be able to move forward to the time when 
there is neither Build.PL nor Makefile.PL.

So underneath, it seems to point to the fact that the toolchain will 
never be upgraded.  Argh!  Just delete 02packages.details.txt and be 
done with it?

--Eric
-- 
But you can never get 3n from n, ever, and if you think you can, please
email me the stock ticker of your company so I can short it.
--Joel Spolsky
---
http://scratchcomputing.com
---

Re: qa: you're doing it wrong

[Eric Wilhelm]

# from David Cantrell
# on Wednesday 03 September 2008 09:57:

>If, like one of my previous employers, you make widgets, you test
>completed widgets, you analyse how they fail, the analyst suggests
>how to improve the manufacturing process to prevent a common failure,
>and TPTB then ignore his report - then "Quality Assurance: you're
>doing it wrong".

So, say I make a super lightweight track bike with skinny tires charged 
to 120psi and a big fixed gear.  Then 40 of my 50 testers take it out 
on the trails and try to jump logs with it, but only one guy takes it 
to the track and the other 9 try to use it to open cans of beets.

They all consider it to have failed, and all of them put their reports 
in a big pile of red paper on my desk.  When I get to the tenth report 
about "bogs down in sand" or "hard to maneuver on logs", I'm probably 
not going to have the stamina to read through the entire pile to find 
the one important report from the tester who took it to the track and 
found that the bottom bracket seized at full speed.

If I see two reports about canned beets, I'm likely to just give up.

So, we all agree that testing is good, but please... test the *code*?

"The old version of the installer is broken"?  So what?

--Eric
-- 
The first rule about Debian is you don't talk about Debian
---
http://scratchcomputing.com
---

Re: git tarballs / tarfile comments

[Aristotle Pagaltzis]

* Graham Barr <[EMAIL PROTECTED]> [2008-09-03 18:35]:
> But the FAIL is record in the wrong place.

Anyone with a CPAN toolchain older than the most recent bleeding
edge version or with a couple-months-old tar binary (ie. everyone
except a number of people indistinguishable from zero) will still
encounter the problem. Your distribution is not backward
compatible with only-barely-outdated software.

That, IMO, is a legitimate flaw in your distribution: current
users with non-ancient system configurations will actually
encounter this problem. I would certainly suggest that you
re-release with a comment-less tarball.

So the FAIL did ding the right place. The inadequacy of Testers
in this case is that there weren’t *enough* FAILs to go around to
account for all the problems that your incident uncovered.
Without manual investigation, this might have gone undetected for
quite a while longer.

But the FAIL did fail to point out the true source of the
problem. And IMO this hints at a real problem that was mentioned
in this thread, but was not really indicted: namely CPAN.pm’s
logic that if there is no Makefile.PL, it is a sane idea to make
one up out of whole cloth. I can’t believe anyone would think
this could ever *ever* work, though Andreas does not strike me as
the type to put harebrained heuristical magic in code. So I have
to wonder what the justification for this behaviour might be. Is
it really necessary or even helpful?

Regards,
-- 
Aristotle Pagaltzis // 

Re: Suppress Test Summary?

[David E. Wheeler]

Damn you, Warnock!

:-P

D

On Aug 8, 2008, at 12:46, David E. Wheeler wrote:


Howdy,

I've started fiddling with the stdout option to TAP::Harness. It's  
nice, although it doesn't capture everything. I mean, I think it  
does, but stuff still gets sent to STDOUT, too. The best way to keep  
stuff from also going to STDOUT appears to be to set verbosity to -2


   -2   really quiet   Suppress everything but the tests summary.

But then, as you can see, it still outputs the test summary. But if  
I have everything going to a file specified via stdout, that seems  
silly.


So I guess I'm wondering why *anything* gets sent to STDOUT when the  
stdout parameter has been set to a file handle?


Thanks,

David

Ignoring Non-Failures

[David E. Wheeler]

On Sep 2, 2008, at 13:23, chromatic wrote:

I already know that my distributions don't work if you don't install  
the
dependencies, or if you use an unsupported version of Perl.  You  
don't have

to waste anyone's time testing that.  What I don't know is if my
distributions work on different operating systems or architectures.   
I'd love
to know that, but if I have to wade through dozens of reports  
containing no

useful information (or worse, sift through FAIL and UNKNOWN reports
containing no useful information about my code), it's not worth my  
time

anymore.  There's no maybe() function in Test::More for a reason.


Like Ovid, I don't mind the dubious FAILs all that much. I always  
query the reporter when it's not immediately apparent to me what the  
problem is (and I've added configure_requires and added a minimum perl  
version to requires in Build.PL to address most of the failures I've  
had), and most are quite responsive, helping me to diagnose failures  
(mainly on Windows -- and David Golden has been very helpful there, I  
might add) or telling me that it was an issue with their infrastructure.


I no longer pay attention to the report emails, though; I don't get  
them all, for some reason. What I now use is the RSS feed:


  http://cpantesters.perl.org/author/DWHEELER.rss

This makes it easy for me to sift through things. The only thing that  
would make it better is if I could get it to display only FAILs. To  
whom should a feature request be sent (I thought I sent a patch to  
acme at one time…)?


Thanks,

David

Re: git tarballs / tarfile comments

[Eric Wilhelm]

# from David Cantrell
# on Wednesday 03 September 2008 06:14:

>> Or, do thousands of people need to learn to do:
>>   man git-tar-tree:
>>          git tar-tree v1.4.0^{tree} git-1.4.0 | gzip
>> >git-1.4.0.tar.gz Create a tarball for v1.4.0 release, but without a
>> global extended pax header.
>
>A better solution might be for EU::MM / Module::Build /
> Module::Install or whatever people use for creating their tarballs to
> learn about git's peculiarities.  I believe that EU::MM at least
> already knows something about CVS and SVN.

Uh... I wonder how this tarball was created.  './Build dist' doesn't 
care if you use git, mercurial, platinibus, or even goldenium.

--Eric
-- 
software:  a hypothetical exercise which happens to compile.
---
http://scratchcomputing.com
---

Re: git tarballs / tarfile comments

[David Cantrell]

On Wed, Sep 03, 2008 at 11:33:30AM -0500, Graham Barr wrote:
> On Sep 3, 2008, at 9:26 AM, David Golden wrote:
> > So do we count this as a win for CPAN Testers?  ;-)
> Sort of, due to the fact the bug did get fixed.
> But the FAIL is record in the wrong place. It gets counted as a FAIL  
> in the distribution because the tester had issues building it that  
> were not really the fault of the distribution.

IMO including Weird Stuff in the distribution that causes CPAN.pm to
throw a fit is a problem with the distribution.  Even though the latest
dev release of CPAN.pm will hide the problem, users who don't stay on
the bleeding edge (that's nigh-on all of them) will still see this
happen, and still wonder why on earth your module won't install.

Anyway, it counts as a win because all the relevant people now know that
there is a problem and what it is.  But it's only a win because the
module author queried the report.  Without having done that, only he
would know that there was something weird happening.

Dragging this back specifically onto the subject of QA - quality
assurance is an iterative process, with feedback.

If, like one of my previous employers, you make widgets, you test
completed widgets, you analyse how they fail, the analyst suggests
how to improve the manufacturing process to prevent a common failure,
and TPTB then ignore his report - then "Quality Assurance: you're
doing it wrong".

My manager's response to my analysis that they'd not be doing anything
is another case of "I don't care why it happens".

(Actually we didn't make widgets - we made things that tell other things
where to go Boom.  Scary.)

-- 
David Cantrell | Hero of the Information Age

All children should be aptitude-tested at an early age and,
if their main or only aptitude is for marketing, drowned.

Re: git tarballs / tarfile comments

[Graham Barr]

On Sep 3, 2008, at 9:26 AM, David Golden wrote:
On Wed, Sep 3, 2008 at 10:19 AM, David Cantrell  
<[EMAIL PROTECTED]> wrote:

On Wed, Sep 03, 2008 at 08:00:49AM +0200, Andreas J. Koenig wrote:

[git comment in tarballs]

CPAN 1.92_64 is uploaded with a workaround for broken tar
implementations.


Thanks, that appears to work.  At least, it Does The Right Thing for
perl-ldap-0.37.


So do we count this as a win for CPAN Testers?  ;-)


Sort of, due to the fact the bug did get fixed.


perl-ldap-0.37 uploaded 28 Aug 2008.  CPAN Testers FAILed it.  Author
complained.  People investigated.  Underlying problem in tar addressed
in CPAN 1.92_64 released on 3 Sep 2008.


But the FAIL is record in the wrong place. It gets counted as a FAIL  
in the distribution because the tester had issues building it that  
were not really the fault of the distribution. So I would still  
advocate changing these FAILs to UNKNOWNs


Graham.

Re: git tarballs / tarfile comments

[David Golden]

On Wed, Sep 3, 2008 at 10:19 AM, David Cantrell <[EMAIL PROTECTED]> wrote:
> On Wed, Sep 03, 2008 at 08:00:49AM +0200, Andreas J. Koenig wrote:
>> > [git comment in tarballs]
>> CPAN 1.92_64 is uploaded with a workaround for broken tar
>> implementations.
>
> Thanks, that appears to work.  At least, it Does The Right Thing for
> perl-ldap-0.37.

So do we count this as a win for CPAN Testers?  ;-)

perl-ldap-0.37 uploaded 28 Aug 2008.  CPAN Testers FAILed it.  Author
complained.  People investigated.  Underlying problem in tar addressed
in CPAN 1.92_64 released on 3 Sep 2008.

-- David

Re: git tarballs / tarfile comments

[David Cantrell]

On Wed, Sep 03, 2008 at 08:00:49AM +0200, Andreas J. Koenig wrote:
> > [git comment in tarballs]
> CPAN 1.92_64 is uploaded with a workaround for broken tar
> implementations.

Thanks, that appears to work.  At least, it Does The Right Thing for
perl-ldap-0.37.

-- 
David Cantrell | A machine for turning tea into grumpiness

  The test of the goodness of a thing is its fitness for use.  If it
  fails on this first test, no amount of ornamentation or finish will
  make it any better, it will only make it more expensive and foolish.
 -- Frank Pick, lecture to the Design and Industries Assoc, 1916

Re: git tarballs / tarfile comments

[David Cantrell]

On Tue, Sep 02, 2008 at 06:21:34PM -0700, Eric Wilhelm wrote:
> # from Jan Dubois
> >On Tue, 02 Sep 2008, David Cantrell wrote:
> >> $ tar tzvf perl-ldap-0.37.tar.gz
> >> ?rw-rw-rw- root/root52 2008-08-28 12:52:15 pax_global_header
> >>unknown file type `g'
> >It is not actually a file, but an extended header record containing
> >a comment (a GIT commit id in this case).  You need GNU tar 1.14 ...
> >Given that GIT is becoming more popular it would be good to teach
> >CPAN.pm to deal with these kind of tarballs even when they are
> >being processed by older tar versions.
> And then CPAN.pm will need to be upgraded ;-)
> >>This might also explain why the distribution doesn't appear on
> >>search.cpan.org.
> The tar on that machine (or PAUSE?) needs an upgrade?

If you think that getting people to upgrade CPAN.pm is hard, I dread to
think how people will react to being told to upgrade tar!  Doubly so for
people who don't use GNU tar.

> Or, do thousands of people need to learn to do:
>   man git-tar-tree:
>  git tar-tree v1.4.0^{tree} git-1.4.0 | gzip >git-1.4.0.tar.gz
>   Create a tarball for v1.4.0 release, but without a global
>   extended pax header.

A better solution might be for EU::MM / Module::Build / Module::Install
or whatever people use for creating their tarballs to learn about git's
peculiarities.  I believe that EU::MM at least already knows something
about CVS and SVN.

-- 
David Cantrell | top google result for "topless karaoke murders"

Godliness is next to Englishness

Re: git tarballs / tarfile comments

[Andreas J. Koenig]

> On Wed, 03 Sep 2008 05:55:19 +0200, [EMAIL PROTECTED] (Andreas J. Koenig) 
> said:

  > (I'll have a look what CPAN.pm can do about this ASAP.)

CPAN 1.92_64 is uploaded with a workaround for broken tar
implementations. Please upgrade:

  cpan> install ANDK/CPAN-1.92_64.tar.gz

Bugreport against Archive::Tar is filed.
http://rt.cpan.org/Ticket/Display.html?id=38932

Thanks for the heads up!
-- 
andreas

Re: git tarballs / tarfile comments

[Andreas J. Koenig]

> On Tue, 2 Sep 2008 18:21:34 -0700, Eric Wilhelm <[EMAIL PROTECTED]> said:

 >> a comment (a GIT commit id in this case).  You need GNU tar 1.14 to
 >> handle the extended header correctly.  Earlier versions will display
 >> a warning and extract the comment as a file.

 ew> Ah, interesting.

 >>> That first file is the problem.  Because the distribution doesn't
 >>> untar cleanly into a subdirectory, CPAN.pm creates a subdir for you
 >>> ... 
 >> 
 >> Given that GIT is becoming more popular it would be good to teach
 >> CPAN.pm to deal with these kind of tarballs even when they are
 >> being processed by older tar versions.

 ew> And then CPAN.pm will need to be upgraded ;-)

 >>> This might also explain why the distribution doesn't appear on
 >>> search.cpan.org.

 ew> The tar on that machine (or PAUSE?) needs an upgrade?

For the record: the tar on PAUSE is 1.16 since December 2006.

(I'll have a look what CPAN.pm can do about this ASAP.)

-- 
andreas