Which brings us to a chicken and egg problem regarding releases. If you make releases often, you identify the issues with releasing and create infrastructure that makes it easier to release. If you don't, then every time you go to make a release, that infrastructure is not there. And things change enough between releases that it is hard to define what that infrastructure should be. So it is much, much easier to maintain a working process than to fix a broken one.

I agree that the Perl 5 release process is broken. Which makes it easy to identify things that would make releases easier. You have identified many. However solving any one of them requires an investment of time and effort. Solving enough of them to make releases take a reasonable amount of effort would require a lot of time and effort. And this is time and effort devoted to something that most people don't like doing.

If you enumerate issues in this case, I agree with you that money won't be the direct problem. You won't find that the bottleneck isn't that you didn't pay for the bandwidth to upload a changed file. However solving the direct problems requires an investment of time and effort. And money is a remarkably good way to get time and effort to be applied to boring problems. So while money isn't the problem, it is likely to be a necessary part of the solution.

I believe we agree far more than we disagree.

What now? How does the Perl community move on from a point where several people believe that the Perl 5 release process needs some major overhaul and other people strongly believe that even discussing that is, at this point, antisocial behavior?

Here is my proposal.

Step 1. Let tempers cool.

Step 2. Publicly ask one or more people who has done the job what would most help the release process. Don't present a solution. Present a question. Publicize the answer.

Step 3. Try to help with ameliorating identified problems. It is likely that many of the problems will be ones that you can't solve directly. That is why mitigation matters.

For instance one major problem is that people do not test new versions of Perl until after they are released, yet the core Perl developers get criticized when stuff breaks. This is at the heart of the whole "darkpan" issue. By definition it is impossible to test the darkpan, and much of it is gnarly code that is deeply integrated with company specific processes and systems. Fears of issues are very reasonable, and mocking those fears will result in emotional reactions that go nowhere.

However those fears can be addressed. In fact much has been done to address them. For a start, look at all of the effort that has been done to add unit tests. Look at the effort involved in maintaining smoke tests. We can go to OS vendors, and try to get them involved. (Debian is a good example. They hate to upgrade Perl because so much depends on it that breaks. Can we go to the Debian community and help them get unit testing so that they can more easily test their Perl dependencies with a new Perl release?) We can get TPF to make sure that there is funding for someone to do a cleanup release in 6 months and limit the potential window of "we've got a broken stable release". Most importantly all of these things (many of which you're already involved in!) can be presented as attempts to address the darkpan issue. This should get a much better response than telling people to not worry about the darkpan.