On Mon, Feb 4, 2013 at 9:49 AM, David Cantrell <da...@cantrell.org.uk> wrote:
> Testers are happy to test modules that are specific to weird legacy
> proprietary OSes, so portability isn't a problem for us. We merely
> encourage people to declare their non-portability in advance.
Well, what about NFS, then?
http://www.time-travellers.org/shane/papers/NFS_considered_harmful.html
While NFS is a reasonable approach to the problem of remote access to
disks, it fails to do so in a way that preserves Unix file semantics.
Using NFS for complex networking issues is often a poorly thought out
attempt to use a simple solution to a complex problem.
NFS suffers from a fundamental design flaw, attempting to find a
compromise between the desire to deal with the network environment
efficiently and preserve existing access semantics. The advertised ability
of NFS to treat network resources as if they were local plainly does not
measure up under close scrutiny.
All the projects I work on are NFS compatible, but the engineering cost to get
them there was way out of scale. And I hate recieving patches that touch NFS
functionality -- because NFS is deceptively difficult to understand, and
because concurrency is hard and concurrency is where NFS fails most subtly,
patches which seem "simple" to the contributor are in fact exhausting to
review.
> No, I think it's authors' responsibility, if they don't want to fall
> foul of the tester running the wrong OS or whatever, to declare their
> pre-requisites, and, if they forget to declare some of them, to be
> prepared to put up with the occasional test failure report.
How does one declare to CPAN testers that a module does not support NFS?
Marvin Humphrey
