On Tue, 23 May 2006 09:35:27 -0500, Chris Dolan <[EMAIL PROTECTED]> wrote:
> On May 23, 2006, at 8:39 AM, David Golden wrote: > > > How does "is_prereq" improve quality? > > > > Or, put differently, how does measuring something that an author > > can't control create an incentive to improve? > > is_prereq is usually a proxy metric for software maturity: if someone > thinks your module is good enough that he would rather depend on it > than reinvent it, then it's probably a better-than-average module on > CPAN. Very true for base modules like Getopt::Long, Test::More, or DBI They are built to be used as basic blocks. DBI on itself is quite useless. It only shows it's value combined with a DBD. The DBD itself however is more unlikely to be required, as it is an end-block. That does not inhibit other authors to extend on it (see DBD::Pg), but the functionality on itself quite often is enough to not invite people to make it a requirement for a new module (see DBD::mysql). These modules however are mature enough to compete. > is_prereq is usually a vote of confidence, I respectfully disagree completely. It's been more than once that I did *not* install a module because it required a module that I did not trust, either because of (the programming style of) the author of that module, or because that module required yet another zillion things I do not want installed (think YAML). > so it is likely a good proxy for quality. In fact I believe that because > the author (usually) can't control it directly, is_prereq is one of the best > proxies for quality among the current kwalitee metrics. I'd say: drop it. It's a worthless metric. > CPANTS by itself does nothing to improve quality. However, by > drawing attention to kwalitee metrics, I argue that CPANTS draws > attention to quality too. Even if many authors don't understand > that, the ones that do makes CPANTS worthwhile. If making it a game > helps to further raise awareness, then I think that should be > tolerated until CPANTS matures. Hurray! Yes, I used it to go over all my modules again, and use Covarage and pod testing because of CPANTS. That indeed increased the qualitee of my modules > IMHO, the best way to improve CPANTS and move away from the game > mentality is to continually add more tests. Each added test > diminishes the weight of previous tests. This will annoy the > "gamers" because their modules keep dropping in kwalitee, while those > that genuinely care about quality will appreciate the additional > measurements. If some gamers get annoyed enough to quit the game, > that's not a big deal because they didn't really understand the point > of CPANTS anyway. If some keep playing the game by cleaving to the > standards the community sets for them, then all the better for the > rest of us. Tests should make sense. I still think there should be a test for copyright notices, and TODO lists. > As an example, consider pod_coverage. It's a rather annoying metric, > most of us agree. Test::Pod::Coverage really only needs to be run on > the author's machine, not on every user's machine. However, by > adding pod_coverage to kwalitee we got LOTS of authors to improve > their POD with the cost of wasting cycles on users' machines. Yep. Here too. > I think that's a price worth paying -- at least until we rewrite the > metric to actually test POD coverage (which is a decent proxy for POD > quality) instead of just checking for the presence of a t/ > pod_coverage.t file (which is a weak proxy for POD quality, but > dramatically easier to measure). -- H.Merijn Brand Amsterdam Perl Mongers (http://amsterdam.pm.org/) using & porting perl 5.6.2, 5.8.x, 5.9.x on HP-UX 10.20, 11.00, 11.11, & 11.23, SuSE 10.0, AIX 4.3 & 5.2, and Cygwin. http://qa.perl.org http://mirrors.develooper.com/hpux/ http://www.test-smoke.org http://www.goldmark.org/jeff/stupid-disclaimers/
