> 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.
It's not an entitlement, it's a shared goal of making Perl better. If a maintainer is going to ignore test reports, perhaps its time to add a co-maintainer. > 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.) Besides the number of straw men starting to fill the room? > 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? That's not my argument at all. But the great majority of non-CPAN.pm-editing build errors can be fixed by the maintainer. Or at least routed around for testing purposes. > "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!" I don't think this is easy at all. But it's also not quite the burden you make it appear. All the testers I've contacted about helping me fix test failures (build or otherwise) have been friendly and responsive. > > 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? Yes, something that indicates the age and number of open bugs for a module, the age of any unapplied patches, and perhaps some other metrics to indicate "maintainedness". Cross referencing that with popularity and dependency chains would be a great triage system to start whipping CPAN into shape. -- Greg Sabino Mullane [EMAIL PROTECTED] End Point Corporation
signature.asc
Description: PGP signature
