Gabor Szabo wrote:
Hi Linda,
I think even if not in this form but similar ideas have been raised
and qucikly rejected using various explanations.
I for one quite agree with your description of the problem so let's think
about a solution that might be accepted or at least that can be implemented
without a broad agreement :-).
---
Some sort of agreement should be necessary from *current*
CPAN developers. Unless you own the site, that is...but don't want
to step on toes of active developers.
I don't want to go off and have another interface without cleaning
up the one that is *most* visible, and most advertised in the process.
Some possible guidelines:
1) adding separate domain names (may go to same site but with different
params used for search and such) "archive.cpan.org" and "devel.cpan.org".
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.
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.
2) Allow modules with long-standing bugs or that don't build under the
current perl be marked for possible archiving.
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.
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').
5) If a module is known to work in a newer release, the newer tag should
be addable by (maybe) any CPAN author with, at least, the Perl version and
the "author" verified it to work on.
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.
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.
I think there should be some interface to CPAN (either search.cpan.org
or elsewhere)
where you would fine the "better" modules.
The only problem of course is that no one can say what "better" is.
---
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.
We already have several tools to measure modules with more or less
relevance.
---
Even 'relevance' isn't as much of a problem -- I mean it can be, but
it's about moving toward some automatic maintenance that would get rid of
stuff that isn't so useful for people, "today" yet would allow working
modules to remain without any action for years (depending on how many
major releases have passed and how often they come out).
Does this sound like a reasonable, concrete and automatable
proposal? If this isn't the best place for this, where would be, "cpan"?
