On Friday 05 September 2008 08:48:36 David E. Wheeler wrote:

> On Sep 4, 2008, at 10:09, chromatic wrote:

> Well, you can ignore the FAILs. Or you can evaluate each one to
> determine if you could change something your code to make it easier
> for your users. No one compels you to do anything.

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

I may have missed a few.

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.

 * 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

> > 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.

> > 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?

> 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).

> > 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.

-- c

Reply via email to