* On Wed, Apr 02 2008, Linda W wrote: > I'd like to see the practice of domain-name squatting...er, I mean > "module-name squatting" squished. Let people develop on devel.cpan.org and > when the owner feels their software ready to be "released" (V1.0) for > general use -- it can be moved to the main base. While I know that releasing > a "spec" or a "plan" as a name reservation has been common practice, I run > across too many modules, that years after their posting date, seem to be > nothing > more than "place holders" for vaporware.
This is annoying, but who cares? The placeholder modules are few and far between. If you want to fix the module, send the author a patch. Or pick a new name and upload your own version. Basically, the CPAN is ad-hoc. Anyone can do whatever they want. Other people have tried to emulate the CPAN, but with restrictions on who can upload what, criteria for inclusion and listing, etc. These projects have been miserable failures. The idea behind the CPAN is that making it easy to contribute will encourage people to contribute. This worked. Adding a bunch of rules is just going to kill the CPAN. (And, why waste your time worrying about theoretical problems that *could* exist, but don't? That's a lot of stress and effort for no gain.) If there are modules on there that you don't like, by all means don't use them. This is Perl; there's more than one way to do it. Your "this is a total hack" may be someone else's "wow, this is a perfect solution." Personally, a lot of modules that are considered "the standard" I wouldn't touch with a 10 foot pole. That doesn't mean they're not useful for other people. > If I was a paranoid person -- one of the best ways to kill CPAN would > be to have every MS employee (just a random example, but came to mind when > I thought of vaporware) sign up under email and submit plans and > bits of partial code to clog up the CPAN namespace and make searching through > it like searching for the proverbial needle in the haystack. If I was a paranoid person, I wouldn't go outside my house because someone on the street could buy a gun and shoot my entire family for no reason. Anyone can buy them, and they kill you instantly! Fear! Thankfully, most people are too lazy to be malicious. Attacking the CPAN would be rather boring. Attacking the CPAN wouldn't gain anyone anything important. People don't do boring things that don't benefit them. (Plus, there are ways of dealing with outright malice. Don't worry, there are people that keep things like viruses and spam out of the CPAN.) The best way to kill the CPAN would be to add a bunch of restrictions on what can be uploaded. Another good way would be to delete modules that have bugs in RT. As an example, WWW::Mechanize has a ton of bugs in RT. It is one of the best modules on the CPAN, though. Basically, it has a lot of users. Whenever they misread the manual, they post a bug report. The author of the module tries to go through these and reply, but it's a big time drain. So it's easier to just let the bugs stay open. There is only so much time in a day; would you rather authors spend their time following your bureaucratic procedures, or adding new features to the modules? I would prefer the latter. > 2) Allow modules with long-standing bugs or that don't build under the > current perl be marked for possible archiving. Your "long-standing bug" may be someone else's feature. Who cares about archiving? What would anyone gain from that? Also, who cares about "the current version"? There are tons of people still using 5.005 and 5.6. There are many, many more people using 5.8 than 5.10. > 3) Modules should be "tagged" by perl-release (5.10, 5.8, 5.6...) that they > are > known to work in. This way, someone who wants a good chance of finding a > module > that will work with 5.10 or 5.8, could limit their search to modules with > those tags in them. In absence of tags in existing modules, a tag can be > added that corresponds to the version of perl that was "out" when the module > was last updated. This functionality already exists, except rather than being a tag, it's actually tested on a variety of perls and platforms. For example, here's a module that says "use feature ':5.10'" at the top. As you can see, it only works on 5.10: http://bbbike.radzeit.de/~slaven/cpantestersmatrix.cgi?dist=App-TemplateServer+0.04 Here's a module that works back to 5.6.2: http://bbbike.radzeit.de/~slaven/cpantestersmatrix.cgi?dist=Algorithm-IncludeExclude+0.01 Pretty easy to determine, and as an author I didn't even have to try my code with 5.6.2. Someone else did it for me! That is much better than tagging. Also, if you want to use a module and aren't sure if it works on your machine, why not just try building it? If it works, it works. If it doesn't, it doesn't. I'm not sure why you would need a tag to tell you that. > 4) Quarterly, modules that have had bugs opened for longer than a year > would have "tags" for the perl-version associated with the bug, "removed" > (indicating the module doesn't work in that version of perl). Nothing would > prevent a module maintainer from re-adding the tag, but hopefully they'll > close out the bug(s) that caused the tag-removal in the first place > (either by fixing it, or marking it as "NOTABUG", "ISAFEATURE", or > "WONTFIX"). (whatever values that make the bug no longer 'active'). More work for authors? I already have to maintain 30 modules. If I have to do work for no reason, you can bet that I won't bother uploading to CPAN in the future. Is that what you want? > 6) Modules that are more than 2 or 3 stable ".versions" 'old' would be > automatically moved to 'archive.cpan.org'. I.e. with 5.10 out, cutoff > would be those modules not marked with tags for anything later than 5.4 or > 5.2 (respectively) (in my mind, something written for 5.4 may or may not work > but if something hasn't been known or marked to work with anything newer > than 5.2, I'd have a low confidence of its current usefulness. There is no such thing as perl 5.4 :P Also, why wouldn't old modules work with new Perls? Perl is supposed to be backwards compatible. And usually is. > Auto expirations would get rid of the stuff that no one cares about (or at > least not enough to check with newer versions) and would prevent crude from > building up, forever, over time. Define "no one". > Not an area I want to address with this -- If it is obsolete > or broken for years, I don't care if it is rated 10 stars, it still > shouldn't clutter up the working CPAN library. It's not hard if someone > wants to 'game' the system. If someone is 'gaming' the system, this isn't > meant to deal with that. It's only meant to slowly expire older, non-working > modules and archive them for historical reference. The core of your argument confuses me. You want to "archive" things. What is the difference between archiving something and not archiving it? You want two search sites, one for non-archived modules and one for archived modules. No offense, but that sounds like a waste of effort. > Does this sound like a reasonable, concrete and automatable > proposal? No, it sounds like an incoherent rant from somebody that knows nothing about the CPAN. Basically, it sounds to me like you're new to the CPAN. After you use it for a few years, you will learn how to find good distributions that will solve your problems. It's called "experience", and is something that only time can bring. Regards, Jonathan Rockway -- print just => another => perl => hacker => if $,=$"
