On Sep 5, 2008, at 10:32, chromatic wrote:

You're right, there's no "compel". If reports don't come by email to people who haven't asked for them, then they'll only get reported via an RSS feed I
can choose to read or not, and on the search.cpan.org pages of my
distributions, which I don't visit.  That's not compulsion, that's
just "offering public data points" in yet another location I can choose to
visit or disregard.  Thus now I can get bug reports via:

* personal mail
* RT web/RSS
* CPAN Forum
* CPAN Testers (email/RSS)
* CPAN Annotations
* CPANTS
* Usenet
* PerlMonks
* countless mailing lists

And if you have to opt-in, I imagine that would solve the biggest complaint, yes? It's the unsolicited email reports that are annoying, right?

In my ideal world, CPAN Testers would be a series of platform combinations where I could submit a development version of a distribution and get test results with the latest version of dependent modules and toolchain modules
*before* uploading to the CPAN.

Well, you can upload a dev version to CPAN and the testing bots will test it, I believe. It'd be nice if there was a separate place to upload code to be tested before you actually released it. That'd be very handy indeed.

* It's opt-in
* It answers my most important question when I want it answered
* It can provide a reference configuration for CPAN installers
* It gives me something I don't already have
* It focuses tester resources where (I believe) they're most appropriate

Yeah, it's a reasonable feature request. Will probably have to wait for the Web service, though.

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 think anyone would argue that. Straw man, dude.

I refer you to Greg Sabino Mullane's posts, in which the gentlest expectation
is:

I recognize that CPAN is a volunteer effort, but it does seem to me there is a implicit responsibility on the part of the author to maintain the module going forward, or to pass the baton to someone else. Call it a Best
 Practice, if you will. The end-user simply wants the module to work.
 Maintainers not paying attention, and the subsequent bitrot that is
 appearing on CPAN, is one of Perl's biggest problems at the moment.
Careful attention and responsiveness to CPAN testers and to rt.cpan.org is
 the best cure for this.

Nothing to do with entitlement. I have hopes for the quality of code, and hope that you'll maintain it, but I don't feel entitled to it.

Obviously it's not always easy to identify the source of the bug. It
is the responsibility of CPAN Testers to run the most recent module in
order to minimize such circumstances.

That would increase the utility of CPAN Testers to me if it were true (at
least, if by "most recent module" you mean toolchain modules).

Yes, I do. And the main CPAN testers do try to stay up-to-date. But getting them all to do so is of course an uphill battle. But certainly those who use bots tend to stay on top of things, IME.

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.
Straw man again. Do you really believe anyone is actually saying that?

I can't find the link, but someone here on Wednesday said "You don't care if people actually use your code", and it's not the first time I've heard it.

Yeah, people can be dicks on mail lists (/me raises his hand), but you don't get that in CPAN Testers reports, do you? You can ignore the assholes. I (usually) do (and FWIW, I didn't notice anything like that in this thread, and David Golden apologized for his out-of-line comment).

Best,

David

Reply via email to