Jonathan Rockway wrote:
* 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.
Actually, I don't know that. Do we have any real numbers?
If you want to fix the module, send the author a patch.
I agree that the author should be contacted, but remember that she is
talking about
placeholder modules that don't have any code. It is probably better to
apply for ownership in
much the same way that the apparently abandoned working modules are.
Write to the list,
apply for co-ownership if the author does not reply (and bear in mind
that sometimes authors
do not reply for weeks, so that you may have spent a lot of time for
nothing).
Or pick a new name and upload your own version.
["What CPAN Is" paragraphs snipped]
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?
Let's be realistic. A long-standing bug is probably a bug. But yes,
archiving would not help.
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.
Um, I certainly care. But on the other hand, it is not a difficult
thing to check either.
[tagging suggestions and responses snipped.]
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.
Not that hard to understand. It's the equivalent of BACKPAN, with the
added feature that only
non-working modules would go there (presumably to be replaced by working
modules in CPAN).
But as before, it is not necessary: apply for module co-ownership if
you have code to fix the module
with and the author is non-responsive.
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.
Okay, that was uncalled for. It wasn't incoherent, and it wasn't a
rant, and trying to be dismissive
like that doesn't help even if the thesis was wrong. I agree that the
problems listed mostly aren't
problems (on the other hand, I'm not going to pretend Time::Cube didn't
happen). Furthermore,
the best solutions to the perceived problems are patch first, apply for
co-ownership second.
Basically, it sounds to me like you're new to the CPAN.
Yeah, probably.
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
-john
