andk's blog

How fresh is the CPAN?

Tim Bunce recently asked in his blog if somebody could remember the posting about the freshness of the CPAN. I suppose he was talking about my posting on use.perl.org . So here is a remake of the stats.

The freshness of a collection is often expressed in quartiles of age answering the questions: 25/50/75 percent of a population is younger than X. So what are the figures for the CPAN? The first question I had to answer is what is the population? Is it the ever uploaded files? The modules contained in them? Only the indexed modules? In my previous posting I did not hesitate to consider currently indexed modules being what most people would consider the population of the CPAN.

For the record, in May 2008 we counted a quarter of the then indexed modules on CPAN had been uploaded within the last 3.8 months. Today we are facing a somewhat less dynamic CPAN, the freshest quarter today is less than 5.6 months old. In May 2008, half of CPAN modules was younger than 17 months, today they are younger than 17.8 months. And three quarters of CPAN had an age below 45 months in 2008, today we see 3/4 being less than 48.8 months old.

The first chart here shows today's figures.

By modules

So do we have a sluggish CPAN now? I don't know, I could imagine the stats are shifting during summer on the northern hemisphere. We'll see this only if we redo the stats more often.

To make this happen I've cleaned up the script that produces the stats.

And while I was at it I tried out the impact what happens if we change the population from modules to distros and to my surprise the figures seemed much more

sluggish.  I'm presenting them in the second chart.

Based on distributions instead of modules

This different picture is due to the fact that younger distros tend to be more complex and contain more
modules. The single-module-distro is out nowadays.

So what is better suited to represent the freshness of the CPAN--a
module based statistics or distribution based one?

I don't know. There are distros that contain many modules and are
still perceived as a single unit. Others are perceived as collection
of modules.

You are the judge.

RT has a spam problem

An inherent spam problem it is. It's a design decision that needs to be
rethunk. RT makers believed that tickets should be creatable through
email which is absolutely a brilliant idea. But they also thought one
and the same email address should be used for the whole life of an RT
installation. And this is what attracts spam and spam detection is hard
work. So what to do?

1. Stop publishing these damn email addresses.

2. It has been suggested by others to introduce a Report As SPAM
button. Yes, please. It would help. Such a button is certainly a good
move, if nothing else a psychological aid. I'd feel relieved when I
could help to defend RT so easily with a simple click. It would still
leave a lot of work behind the scenes to clean up all these reported
spam tickets but this work could be shared or even automated with clever programming.

3. Another thing that should help would be the option to change mail
addresses for queues to unguessable strings. These strings should change
at regular intervals. Not for a single ticket but for the creation of
tickets. This could be done such that at any point in time two or
three addresses are valid and the expiration times are overlapping. I'd
expect this can be programmed in a user friendly way.

I do have delete privileges for rt.cpan.org and have deleted about 5000
spam tickets in the last years. If you have access to the rt.cpan.org database and can provide statistics for
the 5000 deleted tickets I'd ask: in which RT queues did they concentrate? You could quickly decide
which queues urgently need new email addresses.

PS: Perl Programming rocks! And also Euphoria Programming and SuperCollider Programming, of course.

Pause's SSL certificate

Over a year ago PAUSE switched from a self signed SSL certificate to a Cacert-certified one. The advantage of this is that people who have added Cacert to the root certificates in their browser do not need to click through the annoying SSL exception procedure.

So if you have ever clicked through some annoying SSL exception procedure in your browser just to visit PAUSE, sorry for the wasted time.

Better you get your CACERT root certificate into your browser now. Follow their install instructions and be done with it. It's a pity that this browser inclusion stuff doesn't get along and expensive certificate vendors always have a head start because they can afford all kind of demands from browser vendors. And before anybody tells me how politically incorrect this statement was, I'm the first to admit that I do not understand which issues need to be resolved to get Cacert root into all major browsers.

I simply want a workaround. I suggest we all install the root certificate into our browsers and spread the word.

I should probably repeat this blog once a year or so.

A speedier CPAN

Three new sites have started mirroring PAUSE. Every minute. Every
minute? You must be crazy, isn't mirroring always limited to just a few
downloads per day? Doesn't a mere find over 150000 files take a while?
Here's the scoop: The software is a wrapper around rsync that breaks the
limits of mirroring with a new indexing schema. Disclaimer: I wrote the
thing http://search.cpan.org/dist/File-Rsync-Mirror-Recent/

• If you are an admin of a public CPAN mirror and curious enough to join the club let me know and I'll set you up as downloader with username and password.
• If you're interested to use it as an enduser download the module and read the HOWTO.mirrorcpan.
• I'm interested in any feedback and help. Usage scenarios outside CPAN are welcome. Be aware we're still in alpha state, a lot may still change.
  

Perldoc::Server

A module I really enjoyed recently. It's a catalyst standalone server. It's plug and instant play. It gives you all your perl manpages with eye candy and excellent navigation. It's smart and beautiful and gets the one thing right it is designed to do. And it does a lot more than I'd expect from the modest name. Thanks JJ.

Ah, just in case you're having spare tuits. Pod::POM lacks support for

=encoding

and Perldoc::Server depends on Pod::POM and this means in rare cases the encoding of the output page is a bit broken. It's already on the Todo list of the Pod::POM people to support it. Hrm. I wonder if it can be made happen...
Update 2009-05-01: patches for encoding support in Pod::POM in https://rt.cpan.org/Ticket/Display.html?id=45547