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.
In reply to Re^8: When comment turns into disaster
by tilly
in thread When comment turns into disaster
by Tux
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |