On Thursday 04 September 2008 08:30:19 Greg Sabino Mullane wrote: > Sorry, but paying attention is the author's job. A fail is something that > should be fixed, period, regardless of the number of them.
My job is editor, not programmer. Also novelist -- but again, not programmer. Certainly not CPAN programmer. I volunteer as a programmer, but your goals don't automatically become my goals because you want them to become my goals. They only become my goals if we reach some sort of contractual arrangement with mutual consideration, and then only for the scope of the contract. Paying attention is not my job. Releasing software I've written under a free and open license does not instill in me the obligation to jump whenever a user snaps his or her fingers. I may do so because I take the quality and utility of my software seriously, but do not mistake that for anything which may instill in you any sort of entitlement. That is an excellent way not to get what you want from me. > I don't like this: failure by any other name would smell just as bad. In > other words, if an end user is not going to have a happy, functional > module after typing install Foo::Bar at the CPAN prompt, this is a failure > that should be noted as such and fixed by the author. Then CPAN Testers reports should come with login instructions so that I can resurrect decade-old skills and perform system administration to fix broken installations and configurations -- oh, and as you say, a truly *modern* reporting system should publish these logins and passwords publicly in syndication feeds. (I do see a couple of problems with that idea, however.) I fail to understand the mechanism by which CPAN Testers has seemingly removed the ability of testers to report bugs to the correct places. For example, consider Shlomi's earlier message suggesting that a misconfigured CPAN configuration (caused by a bug in CPAN.pm) was the cause of FAIL reports for one of Shlomi's distributions. (I saw and responded to a similar report earlier this week.) Yes, there was a bug and yes, it's important to get it fixed. However, by what possible logic can you conclude that the appropriate way to get that bug fixed is to report it to people who, given all of the information detected automatically, *do not* maintain CPAN.pm? "Oh," perhaps you think, "it's easy for them to read the reports and diagnose the problem remotely on machines they have never seen before, did not configure, and cannot probe -- and it's so easy for them to file a bug in the right place!" If you don't think that, precisely what *do* you think to produce such a bold assertion that it is Shlomi's job to install and reconfigure a new version of CPAN.pm for a CPAN Tester -- or for that matter, everyone with a misconfigured version of CPAN.pm which contains this bug? It's not my "job" to fix bugs in *my own* distributions. I do it because I care about quality and, contrary to what appears to be near-universal belief around here, I care that people can use my code. It is most assuredly not my "job" to fix bugs in distributions I've never maintained, nor report bugs in distributions I may not use, nor report bugs I haven't encountered and diagnosed myself. (The parallels to challenge-response email systems amuse me.) > Thanks for raising it. I honestly feel the problem is not with the testers > or the testing service, but the authors. But perhaps I'm still grumpy from > the slew of modules I've come across on CPAN lately that are popular yet > obviously unmaintained, with bug reports, questions, and unapplied patches > that linger in the RT queues for years. It would be nice if we had some > sort of system that tracked and reported on that. Besides rt.cpan.org? -- c
