in reply to The quantity vs. quality lesson

You've got a good point - is sheer volume worth the loss of quality? However, Borisz also pointed out two issues - 1) who's going to be the judge, and 2) what happens to if things break when supposedly poor-quality stuff is removed.

Perhaps a way around this would be to have two sections on CPAN - one for general modules, and another for modules that have been "certified" or otherwise validated or recognized. I don't know how practical that would be, but at least it would reduce the likelihood of modules being removed that someone relies on.

I didn't understand your comment about having a better implementation, but not being willing to contribute it to thisCPAN. Why not? I can't see that it would do you any harm. But of course, that's your decision...

בּרוּך

Replies are listed 'Best First'.
Re: Re: The quantity vs. quality lesson
by PetaMem (Priest) on Jun 02, 2004 at 07:23 UTC
    Clearly the removal of old modules is the biggest challenge. It is a well known fact, that a big portion of the software and hardware industry has to cope with "Legacy" CPAN and Perl are no exceptions.
    I see several prerequisites for that to be able to happen for every individual module:

    • The module must be OIR (old, infrequent, replaceable), that is: last update n years ago, maintainer has no time, not used often, another - better - module exists and there is a migration path. old2new, which the author of the new one provides (as sign of maintenance commitment). That was for old and replaceable. As for "infrequent" I *do*think, that quite raw download statistics do provide a hint. Yes I have read the statement in the FAQ, I have read the lanl.gov website, and i *do* think that this is the sort of pseudo-academic talk that can make every idea seem moldy.
    • The module gets a deprecated status for time t. In that time, it either gets improved by the original author, or a new maintainer is found, or a seamless migration path is built (1:1 API in a competitive module).
    • After that the module is moved to some CPAN-Nimbus. It is not quite deleted, but if you search on CPAN it is not visible by default.

    Bye
     PetaMem         All Perl:   MT, NLP, NLU

[reply]
      Difficult to judge wether a module is old and unmainted and therefore should be removed.

      Some people just get panic reading something like "last release 1998" , but it could be well written software which does not need any maintance, updates or whatever. The newest ist best! results quite often in usenet messages like "Is (n)vi abandoned?" which I view as a rather funny message. And, shame on me, I regularly use, as a part of my toolbelt, the unix command "diff" and don't even know wether its regularly updated, maintened or whatever.
[reply]
        Actually diff could use some shape up as for intra line and binary diff...

        But if a Module - lets say my favourite Parse::RecDescent will have it's last update in 2001 and we'll have the year 2007, then I see no problem:

        • Keeping it if there will be no other module (and we know Damian won't write it) like Parse::FastDescent with same API, but just functionally equivalent/better and faster.
        • Moving it to CPAN-Nimbus else
        And I'm not saying newest is best. I thought I could discuss at the monastery, on some sophisticated level where it is not necessary to say everything explicitedly.

        Bye
         PetaMem             All Perl:   MT, NLP, NLU

[reply]
      A reply falls below the community's threshold of quality. You may see it by logging in.

In Section Meditations