That's a very selective reading of things. I explained my goals for Perl 5. I asked Rafael specific questions and offered to discuss technical details and to accept any correction for mistakes I've made.

It is not selective reading. It is a conclusion. I carefully stayed out of all release related discussions. It is way too complex. And, to use Jarkko's words, I did not want to get dragged into the vortex. I'm a long time perl contributor, and to keep a healthy state of mind, I try to restrict to the focus areas that were assigned to me: perl configuration and hints. I try to do my best and am always open to suggestions, but when given this responsibility, I can also - within reason - sometimes say "no", which I occasionally did. I hope with enough explanation.

What I understand from all the information that I did read, and I admit that I do not have the full picture, you and rgs did not agree. No problem with that. More people disagree, see Gerard Goossen: he started Kurilla because he did not like the way the rest of perl5 was moving on. But he gave back patches to the `real' perl5 based on his findings, and there has never been an argument/quarrel. Gerard stopped complaining and started something else.

What should I have done differently?

In my perception you went too far in trying to prove that rgs way of dealing with the job he accepted was wrong. Time and time again. I was there at the meeting where Hugo told the perl5 porters that he wanted someone else to take over, and Raphael volunteered. There are not enough people around that have all the qualities that he has. You may dislike some of them, but I for sure do not have most of them. The most important of them all: overview. The community accepted him as Pumpking and perl5 went on.

Personally I will miss this constant factor. He might be more conservative than you or me (I also would make 5.12 have all the features be default), but those were his decisions based on a lot of thought. I never complained. I might have tried to convince him, but not beyond pressure points. e.g. I really tried to keep the "err" keyword.

An alternative road for you could have been to put rejected patches on CPAN, add some docs and tell why it is/was such a great idea. I have maintained the defined-or patch, which was officially rejected for the 5.8.x track, since 5.8.0 and all my perl builds included it. The quality was good enough for it to be documented in the perl5 core.

I do not ask apologies. Shit like this happens. Certainly when volunteers are involved. Maybe none of this would have happened if an eye-to-eye meeting could have been arraanged to talk this all through. Real-life discussions/debates - a.o.t. e-mail/irc/blog/... - quite often help to make people understand eachothers standpoints.

In my perception you went too far in trying to prove that rgs way of dealing with the job he accepted was wrong.

I don't understand this. What have I written that suggests that I am trying to prove that anyone is doing a bad job?

I like Rafael. I respect Rafael. I believe Rafael and the other pumpkings deserve far more respect and appreciation than they get.

I believe the Perl 5 development process is unsustainable, that it hurts the further development of Perl 5, and that it burns out volunteers while discouraging new developers. I don't like that. I have concerns about the future of Perl (and not just Perl 5). I want to see the language and the community succeed, and I invest my time and resources and, yes, even my code to those ends.

I'll take my lumps for saying stupid things and for saying wrong things and for losing my cool sometimes and saying mean, sarcastic, and hurtful things. Tell me what they are and I'll apologize for them. I'll take that blame.

In return, I get told to shut up and go away. I get told to write code instead of talking. I get called a liar and a conspirator. I get labeled deaf and hysterical. I get accused of libel, of trolling, of marketing (?), and of deliberate sabotage. I get threatened with having certain existing accepted patches forcibly removed. I get called dangerously naïve, someone with stupid, crappy ideas only inexperienced novices could possibly believe. I get accused of having hidden agendas, including trying to destroy someone's volunteer work by chasing him away. I get told I should be pleased because I made someone quit working on something he and I both work on and want to see succeed.

I refuse to take that blame.

(If you really want to drive someone away from a project, I believe it's more effective to attack them personally rather than discussing technical decisions and goals and priorities. That's why I try so very often never to attack people.)

Update: Added "deaf", "hysterical", "crappy", and "stupid".

I think you're running afoul of something that I was trying to explain at What you refuse to see, is your worst trap. Which is that if someone puts a lot of themselves into anything, there is a tendency to become emotionally invested in it, at which point they are likely to take technical criticism very personally. This is true no matter how obscure the technical point is. And no, I don't know of a solution. However being aware of the possibility of this failure mode helps me recognize when it is happening, and can sometimes help when I encounter it.

For instance you strongly present your view that Perl 5 should release more often. The people who have done the pain of releasing are likely to hear that as, "You're doing a crappy job." When you talk about how well your projects do on this and how much Perl 5 sucks at it, they are likely to hear, "You're not putting enough effort in." After that point it doesn't matter how much energy you put into pointing out that you're talking about process, not people. Because once people's egos have been hurt, they tend not to read clearly. And they tend to lash back emotionally. As much as we all might wish it were different, this is a natural human reaction.

As a result I strongly disagree with your belief that personal attacks are a more effective way of driving people away from projects than discussing technical decisions and goals and priorities. The most effective way of driving people away is to say things that they take personally. In many cases pointed criticism of someone's technical decisions gets taken more personally than obvious attempts at personal attacks. In those cases technical criticism is much more likely to result in problems than personal attacks. (I've experienced this from both sides, and watched others go through it as well. It is not fun from any perspective.)

It is a very strange phenomenon which made no sense to me for years. But when you review this incident later, I'd suggest focusing on how many times you made technical points and got emotional responses. The solution to that isn't to try to make the technical point more clearly. It is to try to understand where the emotion is coming from, and address the emotional point.

Update: erix pointed out that the singular of phenomena is phenomenon. Fixed.

Looks like there's an annoying bug at the grounds of this communication over ostensibly technical matters. It is a common place that intentions can come across otherwise, and neither sender nor recipient are to be blamed. In the referenced document, you write

Now how do we make the job of a pumpking easier?

Good question. Answers, anyone? I see no comment to that post of yours. -- Rafael was doing his job with inherited proceedings, and it looks like your criticism of organizational matters (as I would put it from what I read, not having digged through all of that) was perceived by him as criticism of his pumpking performance.

Or something like that. Anyways, this is - on both sides - a story of implicit assumptions. How I wish you and Rafael fixed that bug!

Best wishes,
--shmem

Maybe done it sooner? Prepared your interactions better? Accepted decisions already made even if you disagreed with them?

Accepted decisions already made even if you disagreed with them?

This is gonna sound like I'm taking sides, I'm not. I'm sad Raphael feels the need to step down. In this case chromatic has repeatedly described a good faith belief that the current direction of Perl 5 dooms it to heat death. Accepting this course if one cared about Perl would be impossible. Right or wrong, polite or otherwise, he is acting with integrity as I see it.

There are a lot of religious or otherwise nuts people who bomb buildings, kill abortion doctors or commit otherwise atrocious acts, acting in presumably good faith. That may make their behaviour acceptable within their own social norm but doesn't make it better for the victims. So "caring for Perl 5" (whether chromatic does or not) may be necessary but it's not sufficient.

I don't know if he is entirely right, but your list contains no counterexamples to his hypothesis. But it is obvious regular releases are easier if you have a release manager for that purpose, like Samba has in Karolin Seeger. (She is sponsored by a German company named SerNet GmbH.)

Raphael countered by saying that big open source projects with regular release schedules and deprecation cycles have paid developers to help make that happen.

Dave Mitchell has received a TPF grant to make 5.10.1 happen. Booking.com also gave TPF $50,000 for Perl 5 development.

But it is obvious regular releases are easier if you have a release manager for that purpose....

Our experience with Parrot is that regular releases are easier -- even with volunteers -- if you have a dozen people who can make any given release, even if they have only a day's notice.

I don't believe the problem is money.

AFAIK Dave Mitchell's work on 5.10.1 is the first time that someone has been paid to release a version of Perl. Though Sarathy's work on the 5.005 series related enough to his day job at Active State that perhaps that qualified. As for the $50,000 grant, whatever it has been used for, it has not been used to make Raphael's life easier.

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.