Question
To Whom it May concern, I was wondering if I would have your permission to use your phalanx image from your website? My intended use is to put it on the back of our football t-shirts this season. I appreciate your time and effort in considering my request. Thank you, Scott Mallien Southwest High School Green Bay, WI
Re: CPANTS preview - coverage in CPAN testers reports
On Sat, Jul 24, 2004 at 08:05:06PM +0300, Gabor Szabo wrote: > On Sat, 24 Jul 2004, Thomas Klausner wrote: > > > > What about adding (optional) coverage reports to the reports > > > the CPAN testers send in ? > > > > That might be a good idea. But AFAIK, coverage reports can vary greatly on > > different platforms/Perls/installed modules > > IMHO this is exactly the reason it can be interesting to receive it from > several sources. Then CPANTS could display some statistical number about > the reports. Or better still, merge the reports. Any module which has platform specific code, or which can take different paths depending on factors not determined by the module itself, needs to merge reports from all those platforms in order to obtain a true coverage picture. I've had a plan for a while now of some central server where people will be able to upload coverage databases which will then get merged and reports produced. I'm slowly making the changes to Devel::Cover to allow that. When such a system is in place, it could be queried in order to provide some input towards the kwalitee. -- Paul Johnson - [EMAIL PROTECTED] http://www.pjcj.net
Re: CPANTS preview
On Sat, Jul 24, 2004 at 06:35:44PM +0200, Thomas Klausner wrote: > Hi! > > On Fri, Jul 23, 2004 at 03:29:10AM +0100, Tim Bunce wrote: > > > The DBI gets 9. The one failure is permissions_ok: > > > > > permissions_ok (i.e. all files are read/writable by extracting user) > > > > Why is that a kwalitee issue? I don't think it warrants impacting the kwalitee. > > First: Currently there is no real definition of Kwalitee. Now it consists of > stuff that's easy to test and that I'm interested in. Understood. > Personally, I'm annoyed by dist that I cannot remove after installation. > If files are read-only, I'll have to do extra steps during deleting. So I > like dists which no read-only files. Which is why it's a Kwalitee indicator. > > If we (whoever is interested in this issue) deciede that containing > read-only files is not a big issue, than we can drop this indicator (or any > other...) > > But IMO a polite maintainer should make it easy to remove a dist after > installation. I wasn't aware that there was a problem. No one has mentioned in the many many years the DBI has shipped with read-only files. > > p.s. It'll cause problems for anyone using a source code control > > system that keeps files read-only - like RCS and CVS do. > > That's the reason the DBI has many read-only files. > > (I use svn now, but used to use RCS.) > > I think it was also a "problem" with Module::Build / ExtUtils::Manifest. See > here: > http://rt.cpan.org/NoAuth/Bug.html?id=4124 I interpret that as meaning the permissions_ok is primarily driven by the version of MakeMaker used by the author. MakeMaker used to explicitly make the files read-only, now recent versions don't. It's hardly fair to reflect that in the kwalitee metric. > But again: defining Kwalitee is defintly not something I want to do on my > own. I only provided first suggestions ... I expect the definition of Kwalitee to become an uncomfortably hot topic. Meanwhile, I'd suggest you remove permissions_ok :) Tim.
Re: CPANTS preview - coverage in CPAN testers reports
On Sat, 24 Jul 2004, Thomas Klausner wrote: > > What about adding (optional) coverage reports to the reports > > the CPAN testers send in ? > > That might be a good idea. But AFAIK, coverage reports can vary greatly on > different platforms/Perls/installed modules IMHO this is exactly the reason it can be interesting to receive it from several sources. Then CPANTS could display some statistical number about the reports. Gabor
Re: CPANTS preview - coverage in CPAN testers reports
Hi!
On Sat, Jul 24, 2004 at 07:46:30PM +0300, Gabor Szabo wrote:
> On Sat, 24 Jul 2004, Thomas Klausner wrote:
>
> > > - Test coverage.
> >
> > Impossibly, because CPANTS does not run code.
>
> But it could fetch it from some other place that does it, right ?
Right. Back when Leon was maintaining CPANTS there was some talk of having
a "mothership" which could collect infos from various sources.
> What about adding (optional) coverage reports to the reports
> the CPAN testers send in ?
That might be a good idea. But AFAIK, coverage reports can vary greatly on
different platforms/Perls/installed modules (But I'm not a coverage guru...
--
#!/usr/bin/perl http://domm.zsi.at
for(ref bless{},just'another'perl'hacker){s-:+-$"-g&&print$_.$/}
Re: CPANTS preview
Hi!
On Fri, Jul 23, 2004 at 08:41:58AM +0200, James Mastros wrote:
> - Having POD
> - Not having the POD that h2xs puts in
I wonder how many dists are authored by R.U. Thor :-)
> - Having a README
thats allready covered.
> BTW, I tend to think that modules that require lots of other things
> deserve lower kwalitee...
Why?
> and that perhaps in addition to kwalitee we
> should attempt to track importance.
Hmm, I was thinking of importance beeing a part of Kwalitee. It seems to
make sense, but I think it will be to complicated now. Maybe later?
> You can get importance for:
> - being listed as a (prereq|recommendation|build_prereq) for something
> else (in relation to the importance of that thing)
> - having lots of CPAN testers reports
> - having lots of RT activity
> - having lots of rating votes
> - having good rating votes
> (The two above can probably be simplified by taking the sum of all
> rating votes.)
> - Being the most recent version of the dist in question
> - Not being a devel (IE with-underscore) version.
BTW, it should be possible to use the raw data to calculate importance. So
maybe all that's needed is a script that does some SQL munging...
> BTW, all modules should probably be considered to depend on perl itself,
> no matter what the metadata we have says -- otherwise perl gets an
> unfairly low importance.
CPANTS doesn't test Perl itself.
> BTW, what's $report->{files}{ninja}?
see here:
http://use.perl.org/comments.pl?sid=21487&op=&threshold=0&commentsort=0&mode=thread&tid=34&pid=32773#32817
> A standalone tester would be very nice -- so authors can test their
> kwalitee before they upload, rather then after.
Thats also planned. Something like 'lint' for dists.
> There's a couple of misspelled fields in the kwalitee report.
Which ones?
--
#!/usr/bin/perl http://domm.zsi.at
for(ref bless{},just'another'perl'hacker){s-:+-$"-g&&print$_.$/}
Re: CPANTS preview - coverage in CPAN testers reports
On Sat, 24 Jul 2004, Thomas Klausner wrote: > > - Test coverage. > > Impossibly, because CPANTS does not run code. But it could fetch it from some other place that does it, right ? What about adding (optional) coverage reports to the reports the CPAN testers send in ? Gabor
Re: CPANTS preview
Hi!
On Fri, Jul 23, 2004 at 04:56:40AM +0200, Paul Johnson wrote:
> At the moment the focus seems very much on packaging. That's fine, but
> it does mean that "correctly" packaged junk looks pretty good.
True, but most junk /is/ packaged badly.
At its much easier to check for bad packages than for bad content. See this
for Schwerns great Ashtray/Lung Cancer Methapher:
http://magnonel.guild.net/~schwern/talks/CPANTS/full_slides/slide006.html
> In time,
> some more metrics would be good.
definitly!
> Some suggestions:
>
> - How do the CPAN testers reports look?
> - What does cpanratings think?
> - Some analysis of the RT action.
> - Number of releases, perhaps in relation to the size of the code.
>More releases expected for larger code.
all planned to some extend or the other...
> - Static analysis.
Hard, but planned.
> - Test coverage.
Impossibly, because CPANTS does not run code.
--
#!/usr/bin/perl http://domm.zsi.at
for(ref bless{},just'another'perl'hacker){s-:+-$"-g&&print$_.$/}
Re: CPANTS preview
Hi!
On Fri, Jul 23, 2004 at 03:29:10AM +0100, Tim Bunce wrote:
> The DBI gets 9. The one failure is permissions_ok:
>
> > permissions_ok (i.e. all files are read/writable by extracting user)
>
> Why is that a kwalitee issue? I don't think it warrants impacting the kwalitee.
First: Currently there is no real definition of Kwalitee. Now it consists of
stuff that's easy to test and that I'm interested in.
Personally, I'm annoyed by dist that I cannot remove after installation.
If files are read-only, I'll have to do extra steps during deleting. So I
like dists which no read-only files. Which is why it's a Kwalitee indicator.
If we (whoever is interested in this issue) deciede that containing
read-only files is not a big issue, than we can drop this indicator (or any
other...)
But IMO a polite maintainer should make it easy to remove a dist after
installation.
> p.s. It'll cause problems for anyone using a source code control
> system that keeps files read-only - like RCS and CVS do.
> That's the reason the DBI has many read-only files.
> (I use svn now, but used to use RCS.)
I think it was also a "problem" with Module::Build / ExtUtils::Manifest. See
here:
http://rt.cpan.org/NoAuth/Bug.html?id=4124
But again: defining Kwalitee is defintly not something I want to do on my
own. I only provided first suggestions ...
--
#!/usr/bin/perl http://domm.zsi.at
for(ref bless{},just'another'perl'hacker){s-:+-$"-g&&print$_.$/}
