Michael Graham wrote:
If someone were to take over maintenance of your module, or they were to
fork it, or they were submitting patches to you, then they would want
these tools and tests, right? How would they get them?
By asking for them?
It is my experience that when someone takes over
On 17 Apr 2005, at 11:09, Tony Bowden wrote:
On Sun, Apr 17, 2005 at 08:24:01AM +, Smylers wrote:
Negative quality for anybody who includes a literal tab character
anywhere in the distro's source!
Negative quality for anyone whose files appear to have been edited in
emacs!
Ow! Coffee snorted
On 17 Apr 2005, at 13:47, David A. Golden wrote:
[snip]
2) A metric to estimate the quality of a distribution for authors to
compare their work against a subjective standard in the hopes that
authors strive to improve their Kwalitee scores. In this model,
faking Kwalitee is irrelevant, because
Adam Kennedy writes:
Christopher H. Laco wrote:
Tony Bowden wrote:
What's the difference to you between me shipping a a .t file that
uses Pod::Coverage, or by having an internal system that uses
Devel::Cover in a mode that makes sure I have 100% coverage on
everything,
Adam Kennedy writes:
Michael Graham wrote:
Another good reason to ship all of your development tests with code
is that it makes it easer for users to submit patches with tests.
Or to fork your code and retain all your development tools and
methods.
Perl::MinimumVersion, which
chromatic writes:
On Sat, 2005-04-16 at 20:59 -0500, Andy Lester wrote:
And the more the better!
Well sure. Two-space indent is clearly better than one-space indent,
and four-space is at least twice as good as that.
Negative quality for anybody who includes a literal tab character
On Sun, Apr 17, 2005 at 08:24:01AM +, Smylers wrote:
Negative quality for anybody who includes a literal tab character
anywhere in the distro's source!
Negative quality for anyone whose files appear to have been edited in
emacs!
Tony
On Sun, Apr 17, 2005 at 12:17:17AM +, Smylers wrote:
Remember that we aren't measuring quality, but kwalitee. Kwalitee is
supposed to provide a reasonable indication of quality, so far as that's
possible. So what matters in determining whether a kwalitee heuristic
is appropriate is
Tony Bowden wrote:
so even if a neural net (or whatever) did come up
with the above substring heuristic, once it's know then authors can game
the system by artificially crowbarring into their modules' sources, at
which point the heuristic loses value.
I thought the idea was that we /wanted/
Tony == Tony Bowden [EMAIL PROTECTED] writes:
Tony Negative quality for anyone whose files appear to have been edited in
Tony emacs!
Now, them's fightin' words!
--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
merlyn@stonehenge.com
Christopher H. Laco wrote:
Tony Bowden wrote:
On Thu, Apr 07, 2005 at 12:32:31PM -0400, Christopher H. Laco wrote:
CPANTS can't check that for me, as I don't ship those tests.
They're part of my development environment, not part of my release
tree.
That is true. But if you don't ship them, how
Michael Graham wrote:
Another good reason to ship all of your development tests with code is
that it makes it easer for users to submit patches with tests. Or to
fork your code and retain all your development tools and methods.
Perl::MinimumVersion, which doesn't exist yet, could check that the
Michael Graham wrote:
Another good reason to ship all of your development tests with code is
that it makes it easer for users to submit patches with tests. Or to
fork your code and retain all your development tools and methods.
Perl::MinimumVersion, which doesn't exist yet, could check
On Sat, 2005-04-16 at 19:31 -0400, Michael Graham wrote:
I'm not suggesting that end users be forced to *run* your development
tests. Just that the tests be included in your CPAN package. Ideally,
the install process can be made smart enough to skip this kind of test.
Shipping tests but not
I'm about halfway ready to propose 'has_indentation' as a kwalitee
metric.
And the more the better!
--
Andy Lester = [EMAIL PROTECTED] = www.petdance.com = AIM:petdance
On Sat, 2005-04-16 at 20:59 -0500, Andy Lester wrote:
I'm about halfway ready to propose 'has_indentation' as a kwalitee
metric.
And the more the better!
Well sure. Two-space indent is clearly better than one-space indent,
and four-space is at least twice as good as that.
It falls down a
On Thu, Apr 07, 2005 at 02:34:21PM -0400, David Golden wrote:
* Shipping tests is a hint that a developer at least thought about
testing. Counter: It's no guarantee of the quality of testing and can
be easily spoofed to raise quality.
This is certainly not why I ship tests, and I've never
in the middle of a fetch?
Why not find a way to include them in the META.yml file and have the
build tools keep track of whether pod/pod-coverage/code-coverage was
run? Self reported statistics are easy to fake, but so are the
has_test_* Kwalitee checks as many people have pointed out.
Not quite sure
Another good reason to ship all of your development tests with code is
that it makes it easer for users to submit patches with tests. Or to
fork your code and retain all your development tools and methods.
Since most Perl modules go up on CPAN and nowhere else, I think that the
CPAN
David Cantrell wrote:
Thomas Klausner wrote:
I cannot check POD coverage because Pod::Coverage executes the code.
No it doesn't. That said, if you don't want to run the code you're
testing, you are, errm, limiting yourself rather badly.
Do YOU want to run all of CPAN?
I certainly don't.
Bulk
Adding a kwalitee check for a test that runs Devel::Cover by default
might on the surface appear to meet this goal, but I hope people
recognize it as a bad idea.
Why, then, is suggesting that people ship tests for POD errors and
coverage a good idea?
Although I've now added the automated inclusion
Hi!
On Thu, Apr 07, 2005 at 01:17:40PM +1000, Adam Kennedy wrote:
Adding a kwalitee check for a test that runs Devel::Cover by default
might on the surface appear to meet this goal, but I hope people
recognize it as a bad idea.
Why, then, is suggesting that people ship tests for POD errors
On Thu, Apr 07, 2005 at 08:56:26AM -0400, Christopher H. Laco wrote:
I would go as for to say that checking the authors development
intentions via checks like Test::Pod::Coverage, Test::Strict,
Test::Distribution, etc is just as important, if not more, than just
checkong syntax and that all
Tony Bowden wrote:
On Thu, Apr 07, 2005 at 08:56:26AM -0400, Christopher H. Laco wrote:
I would go as for to say that checking the authors development
intentions via checks like Test::Pod::Coverage, Test::Strict,
Test::Distribution, etc is just as important, if not more, than just
checkong
On Thu, Apr 07, 2005 at 12:32:31PM -0400, Christopher H. Laco wrote:
CPANTS can't check that for me, as I don't ship those tests.
They're part of my development environment, not part of my release tree.
That is true. But if you don't ship them, how do I know you bothered to
check those things
Tony Bowden wrote:
On Thu, Apr 07, 2005 at 12:32:31PM -0400, Christopher H. Laco wrote:
CPANTS can't check that for me, as I don't ship those tests.
They're part of my development environment, not part of my release tree.
That is true. But if you don't ship them, how do I know you bothered to
On Thu, 2005-04-07 at 13:22 -0400, Christopher H. Laco wrote:
How as a module consumer would I find out that the Pod coverage is
adequate again? Why the [unshipped] .t file in this case.
How as a module consumer would you find out that the test coverage is
adequate?
Furthermore, what if I as
-coverage/code-coverage was
run? Self reported statistics are easy to fake, but so are the
has_test_* Kwalitee checks as many people have pointed out. Anyone who
is obsessed about Kwality scores is going to fake other other checks,
too. And that way, people who have customized
Subject: Re: Kwalitee and has_test_*
From: David Golden [EMAIL PROTECTED]
Date: Thu, 07 Apr 2005 14:34:21 -0400
}What if I, as a developer, choose to run test as part of my development
}but don't ship them. Why should I make users have to spent time waiting
}for my test suite to run?
Let's
Yitzchak Scott-Thoennes wrote:
Since you ask...
An important part of kwalitee to me is that Makefile.PL / Build.PL run
successfully with stdin redirected to /dev/null (that is, that any
user interaction be optional).
Another is that a bug-reporting address or mechanism (e.g. clp.modules
or cpan
Hi!
On Mon, Apr 04, 2005 at 10:32:14AM +0100, David Cantrell wrote:
Thomas Klausner wrote:
I cannot check POD coverage because Pod::Coverage executes the code.
No it doesn't.
Yes, it does.
Pod::Coverage uses Devel::Symdump to get a list of all subs.
That said, if you don't want to run
On Fri, Apr 01, 2005 at 09:00:17PM +0200, Thomas Klausner wrote:
Well, kwalitee != quality. Currently, kwalitee basically only says how
well-formed a distribution is. For my definition of well-formed :-) But I'm
always open to suggestion etc.
Since you ask...
An important part of kwalitee to
On Sun, Apr 03, 2005 at 03:09:17PM -0700, Yitzchak Scott-Thoennes wrote:
Since you ask...
An important part of kwalitee to me is that Makefile.PL / Build.PL run
successfully with stdin redirected to /dev/null (that is, that any
user interaction be optional).
Another is that a
Hi!
On Sun, Mar 27, 2005 at 11:40:45AM +0100, Tony Bowden wrote:
There are now two kwalitee tests for 'has_test_pod' and
'has_test_pod_coverage'. These check that there are test scripts for
POD correctness and POD coverage.
Actually they check if Test::Pod and Test::Pod::Coverage are used in
On Fri, 2005-04-01 at 21:00 +0200, Thomas Klausner wrote:
On Sun, Mar 27, 2005 at 11:40:45AM +0100, Tony Bowden wrote:
We should be very wary of stipulating HOW authors have to achieve their
quality. Saying you can only check your POD in one specific way goes to
far IMO.
That's a good
Hi!
On Fri, Apr 01, 2005 at 10:59:04AM -0800, chromatic wrote:
Why, then, is suggesting that people ship tests for POD errors and
coverage a good idea?
I'm not 100% sure if it's a good idea, but it's an idea.
But then, if I write some test (eg to check pod coverage), why should I not
ship
On Fri, 2005-04-01 at 21:43 +0200, Thomas Klausner wrote:
But then, if I write some test (eg to check pod coverage), why should I not
ship them? It's a good feeling to let others know that I took some extra
effort to make sure everything works.
If I use Devel::Cover to check my test coverage,
On Fri, Apr 01, 2005 at 09:00:17PM +0200, Thomas Klausner wrote:
Anyway, I invite everybody to suggest new metrics
I'd like the is pre-req thing to be more useful. Rather than a binary
yes/no thing (and the abuses it leads to), I'd rather have something
akin to Google's Page Rank, where the
I was having a look at CPANTS again this morning, and I noticed
something rather strange.
There are now two kwalitee tests for 'has_test_pod' and
'has_test_pod_coverage'. These check that there are test scripts for
POD correctness and POD coverage.
These seem completely and utterly wrong to me.
These seem completely and utterly wrong to me. Surely the kwalitee
checks should be purely that the POD is correct and sufficiently covers
the module?
One problem I can see with this is that (I think) the only way to
indicate extra private methods is to do so in pod-coverage.t. For
instance:
40 matches
Mail list logo
