Yesterday (August 16th 2014) we celebrated the anniversary
of the first upload to CPAN
by Andreas König (ANDK)
(as he worked on what became PAUSE).
It was the 19th anniversary, but the first that we've marked in this way.
In one day, 107 people uploaded 775 releases, 41 of which were the first
uploads of new distributions, and 10 of which were the first upload
by new CPAN contributors. The first two numbers were outright records,
and the second equalled the previous best. All of those numbers were higher than I expected.
My project for CPAN Day has been to pull together a history of CPAN:
- How it was started, and by whom
- The other services that make up the CPAN ecosystem
- The key modules that have helped shape CPAN
In best CPAN tradition, this is the work of dozens of people, who patiently responded to my pestering via email over the last few weeks. Thanks to everyone who helped get it to this point.
CPAN Day (August 16th, UTC) is nearly here. Someone asked me what the goals are,
if any, for CPAN Day. When BOOK came up with the idea, we both
thought it was an opportunity to celebrate CPAN, but also a chance
to reflect on how we got here, and to think about how we can keep
driving it forward.
I also saw it as an opportunity to bang on my curation drum —
give everyone ideas for how they might improve their distributions,
or those of others, and in doing so improve the overall quality of CPAN.
CPAN was created by us, for us, so do whatever feels right to you.
If you do something for CPAN Day,
please tweet about it with the #cpanday hashtag.
Travis is a continuous integration (CI) platform for github users,
which is free to use.
You can set it up so that
every time you push one of your CPAN distributions to github,
Travis will test it against different versions of Perl.
I've only just started playing with Travis, but I can already see
benefits for using it in parallel with CPAN Testers.
Why not give it a go on CPAN Day? :-)
It's a good idea to specify the minimum Perl version required by your distribution. It's useful information for people looking at your code, it's helpful for CPAN Testers (which will report NA for old perls, rather than failing), and it makes the requirement clear to people who are trying to install your module on an older Perl.
If your CPAN distributions aren't already on github, then I think you should consider adding them. Github is the most popular code hosting service, so it's the first place many people will look for your code.
If your distributions are on github, it makes it a lot easier for people to submit changes (like bug fixes) via pull requests. And if it's easier, it's more likely that people will.
If you do add your dists to github, then you should make sure that you give the repo in the dist's metadata and the documentation too.
Last week I encouraged y'all to fix a bug or two on CPAN Day, either in your distributions, or in someone else's. To help you, I listed the top 20 dists by bugs.
David "never satisfied" Golden pointed out that the table would be more useful / interesting if broken down by severity. So here it is. This also reveals that a lot of tickets don't have a severity set, so on CPAN Day we should sort that out too!
There's a well known saying, "it takes a village to raise a child". I think our equivalent is something like "it takes a community to raise a CPAN distribution". There are very few modules on CPAN that have been purely the work of one person. You get bug reports, pull requests, feature ideas, typos reported by D Steinbrunner, and so on.
All of these interactions nudge your distribution down the road, encourage you, inspire you, and sometimes annoy you. But they all help make your distributions what they are. So on CPAN day, maybe you could acknowledge them in your documentation?
It's all too easy to take CPAN for granted, particularly the modules and distributions
that just work, and continue to do so year in, year out.
Take a moment to thank the author or maintainer of one of your "go to" modules on CPAN Day (16th August).
I tried this: the recipient seemed to like it, and it made me feel good too.
For CPAN Day, you could check the test coverage for your distributions using Devel::Cover. If your distributions are already covered, or you don't have any distributions, take a look at the coverage results for some other dists on CPAN Cover, and maybe you could submit something for someone else's dist.
The DESCRIPTION section of your module's documentation should come after, and provide the narrative for, the SYNOPSIS. In particular, make sure that the first paragraph is a good summary of what your module does / provides. After the abstract, the first paragraph is your most powerful tool in selling your module to potential users.
For CPAN Day (next Saturday 16th August), make sure all your modules have a DESCRIPTION section in the pod, and that the first paragraph is a good summary. And if you do, tweet about it, using the hashtag #cpanday.
If you're a module author, and looking for something to release on CPAN Day, have a look at your CPAN Testers results. If you've got any failures, check the test report(s) and see if you could release an update to prevent those in the future.
If you're still looking for something to do on CPAN Day (Sat 16th August), you could fix a bug in a CPAN distribution. It might be a bug in one of your own distributions, but it doesn't have to be — you could fix a bug in someone else's distribution. If their dist is on github you could send them a pull request, otherwise attach a patch to the issue in RT.
On Saturday I wrote about naming your distribution, and how that should be based on your (lead) module name. ETHER pointed out that if your module is sub-optimally named, then you should also consider renaming your module (and thus probably the distribution) on CPAN Day.
I thought it would be helpful to expand on that, and give some pointers to resources that might help you with naming.
When you release your module to CPAN, you should make sure that the distribution has the right name. Doing so makes it more likely that all the different tools and systems in the CPAN ecosystem can process your distribution. I'll outline what I mean by that, and how you can get it right. If one or more of your distributions doesn't follow the conventions, maybe you could release a fix on CPAN day?
CPANTS bills itself as a "testing service for CPAN distributions". It calculates a kwalitee score for all distributions. It doesn't test the quality of your code, but instead evaluates whether your distribution follows various conventions.
Being 'CPANTS clean' means that your distribution is more likely to behave well with the CPAN toolchain, the ecosystem of CPAN-related services, and ad-hoc tools that various people write.
If you haven't thought of something to release on CPAN Day (Sat August 16th), have a look at your CPANTS author's page.