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
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 do
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 maintenan
> "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
http://www.stonehenge.com/merlyn/>
Perl/Un
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/ people
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 wh
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
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, w
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 characte
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
> > > ev
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 do
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 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
> 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, coul
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
v
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 do
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 distribution
On 07 April 2005 19:34 David Golden wrote:
> Let's step back a moment.
>
> Does anyone object that CPANTS Kwalitee looks for tests?
I think you're missing the point of Tony's argument. I don't think anyone would
dispute that shipping tests with a distribution is a Good Thing (tm). What is at
i
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
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
Let's step back a moment.
Does anyone object that CPANTS Kwalitee looks for tests? Why not apply
the same arguments against has_test_* to test themselves? 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 wa
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 a
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
chec
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 t
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 synta
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
This is an interesting point and triggered the thought in my mind that
CPANTS "Kwalitee" is really testing *distributions* not modules -- i.e.
the quality of the packaging, not the underlying code. That's
important, too, but quite arbitrary -- insisting that distributions test
pod and pod cove
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 and
coverage a good idea?
Although I've now added the
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 PO
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
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 te
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 t
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.
--
David Cantrell
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
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 bug-r
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 t
Tony Bowden wrote:
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 Ra
On Fri, Apr 01, 2005 at 09:00:17PM +0200, Thomas Klausner 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 point.
> OTOH, I know of several people who added Pod
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 s
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 coverag
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: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'
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
> 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
instanc
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?
Especially because pod.t and pod-coverage.t don't need to actually get
distributed with the module. Perhaps I keep pod*.t in my Subversion
reposi
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.
46 matches
Mail list logo
