# from Andy Lester
# on Friday 05 September 2008 09:34:
>> Well, yeah, I have too. And sometimes I make a tweak to get things
>> working on 5.005, and other times I tell my users that it runs 5.006
>> or later by saying so in Build.PL. Seems reasonable to me to
>> specify such dependencies.
>
>"Seems reasonable to me" is EXACTLY my frustration. That is YOUR
>standard that YOU are specifying.
>
>How about if I start sending email to everyone, whether they want it
> or not, if their code doesn't run under -T checking? It seems
> reasonable to me that it should.
Yes. The mail thing is clearly a rub (especially if it isn't
comprehensive or centrally configurable.)
Putting a big red flag on a dist for not running under taint would also
be a bit severe - but a yellow "notaint" flag might be appropriate and
it is useful information.
But I'm talking about the view of the reports.
>> hope you'll tell your users about a Perl version dependency
>
>This is beyond me and my frustration about getting worthless emails.
> It is about the presumption of telling CPAN authors ...
> punishing them for not bending to the whims of the CPAN Testers
So, let's please move on from complaining about the mail. I hope we all
can agree that opt-out is annoying.
I think the presentation of the reports is what needs improvement, and I
think we need to come to some consensus on what is a reasonable default
presentation. There is indeed some aspect of reward and punishment to
what you present about an author's code.
Note: Notifications are just one aspect of presentation (and are not
limited to the author for that matter.)
It should not be a "big red deal" if an author omits the declaration of
requiring perl 5.8.mumble+. At this point, it is a reasonable
assumption that code "should" run on 5.8.8 and 5.10.+, but an
unreasonable assumption that it runs on 5.6.x or less.
It should not be a "big red deal" if a distribution doesn't run on VMS.
This is not a system many people have ready access to or interest in.
It should not be a "big red deal" if a distribution doesn't install on a
non-updated toolchain.
I'm not saying that you should not test for these things. Try to run it
on a toaster or whatever. That's useful data to some people (and hey -
"dude! My code passes all tests on a toaster!" is a great conversation
starter.) But a big stack of red FAIL's in the default presentation
from all toasters and VMS is just unreasonable, right?
As I mentioned before, I would love to have any user or author be able
to configure their own various modes of presentation. A VMS user
really does want to see a big stack of FAIL when that's the case.
And 5.6.x- is the same way. Maybe it works. Maybe the author will tag
the next distro that 5.6 doesn't work, whatever. It's just not that
important to the majority of users and authors at this point. (IF it
is, that's a different problem and there will never be a funpan.)
And I hope perhaps that we've finally reached the point where a user can
reasonably be expected to upgrade their toolchain before trying to
install the latest and greatest of *everything else*. If we must shove
a toolchain update down the user's throat, we have got the entire rest
of the CPAN completely wrong.)
Now, currently, the presentation of notifications is both out of the
cpantesters control *and* out of the author's control. That causes
conflict that nobody is really in a position to immediately resolve.
Now, also currently, there is only one web-view presentation of the
reports on search.cpan.org and cpantesters.perl.org. This also causes
conflict:
* If anybody starts a VMS smoker, the entire CPAN is likely to
light-up red, which (I hope we can agree) is unreasonable.
* An author using Module::Build is still in a rock vs hard place
* An author writing in 5.8ese has to add "no, not perl4" checks to
keep from seeing red.
* Win32? What if half of the smokes were on Win32? How red would
that be? Hey, a valid usage of the OS from the browser identifier?
So, what *is* a reasonable set of expectations from a modern perl user?
We should expect that to be an evolving set of expectations
as "reasonable" adjusts to keep up with new releases, etc. If the
presentation is fluid, the defaults can evolve and if it is
configurable, the holdouts can set their own view of it.
The question then becomes a matter of what you (by default) present to
the world about an author's code and not just which data has been
gathered. Thus: What does the default fail-o-meter look like and what
does it mean?
That should basically encapsulate what a reasonable author would be
willing to shoot for as a mark of quality. Everything else should be
something they *want* to shoot for as a badge of excellence.
Thanks,
Eric
--
"Beware of bugs in the above code; I have only proved it correct, not
tried it."
--Donald Knuth
---------------------------------------------------
http://scratchcomputing.com
---------------------------------------------------
