Apologies for going silent since I sent my initial email, I've been trying to learn a new keyboard and it's not been great for productivity.
ribs- Thank you for considering it and starting some research. Deleting them from the main CPAN and letting them remain on backpan seems like a very reasonable direction. The needs of CPAN and backpan are very different. Backpan is significantly larger, but gets significantly less traffic and has lower performance requirements. For example, there's no requirement to support fast mirroring. As Ask pointed out, the data shows that these files get very little traffic. Elsewhere in the thread it was noted that the same content can be retrieved from Git. Not many people will be inconvenienced. Todd said: > I’m unclear who decides if it’s OK for me to delete the dev versions of > Perl I’ve done. I’m happy to do it. Maybe we should put a policy or > suggestion into the release manager’s guide as a first step? I think that's what we're trying to figure out. Unless someone (rjbs?) comes up with a reason why not to, it would be cool to have a policy that dev releases get deleted TBD months after the next release, or something similar. Thanks- -R On Tue, Apr 5, 2022 at 2:54 AM Ask Bjørn Hansen <a...@perl.org> wrote: > That’d make sense to me, deleting the old images and letting them just be > on backpan. That should allow whatever tooling depends on recent releases > being in the regular CPAN mirrors to still work. > > Looking at 3 days of www.cpan.org logs only the most recent development > image seems to have been downloaded more than the background noise of > everything getting a request now and then because web crawlers. (And the > most recent development image by just number of downloads recently is less > popular than about a dozen very old not-development releases). > > I put a CSV of the counts of “perl5-“ URLs temporarily at > https://tmp.askask.com/os/cpan/cpan-perl-downloads-2022-04-05-02_13_21.csv > > > Ask >
