On 20/09/17 02:40, C. Scott Ananian wrote:
For example, the top-line github stats are: hhvm: 504 contributors (24,192 commits) php-src: 496 contributors (104,566 commits)
There's a reason I've contributed loads of code to HHVM and hardly any to PHP. Although the HHVM folks were sometimes tied up in internal work and not available, when they were available, my interactions with them were very pleasant. They were enthusiastic about my contributions, and were happy to have long design discussions on IRC. Code review sometimes had a lot of back and forth, but at least they were positive and engaged. The people I dealt with in code review usually had it as their job to accept community contributions. My bug reports were respectfully treated.
It was a big contrast to my interactions with the PHP community, which were so often negative. For example, Jani's toxic behaviour on the bug tracker, closing bugs as "bogus" despite being serious and reproducible, usually because he didn't understand them technically. Even with other maintainers, I had to fight several times to keep serious bugs open. I had no illusions that they would ever be fixed, I just wanted them to be open for my reference and for the benefit of anyone hitting the same issue. I filed bugs as "documentation issues", requesting that undesired behaviour be documented in the manual, since they were more likely to stay open that way.
My interactions with Derick Rethans were quite unpleasant, he would not even consider accepting the code I wrote to fix a DoS vulnerability which was affecting us constantly. He wouldn't provide a code review, he just rejected it on principle. Instead he wrote his own version of it a couple of years later. He seemed to think that every line of code in the date module should be attributable to him.
Design discussions are apparently concentrated on the internals mailing list, where there is an incredible amount of negativity for any new idea. Developers really need a lot of energy to keep answering negative comments, over and over for a period of months, in order to get their RFCs accepted. Some language features which eventually made it into PHP, such as short arrays, were shot down many times on the mailing list before they found a champion who was sufficiently brave and influential.
Their code review practices were quite archaic, I don't know if they've improved. Their coding style is also dated.
Stas was great, a bright spot in a dismal field, which was why I was so keen to hire him.
So I'm not looking forward to returning to PHP. But at least we know what we are getting ourselves in for. Being community-driven means it has inertia, change is slow. Facebook have been inconsistent with HHVM, and have made it clear that they don't intend to cater to our needs.
-- Tim Starling