Being the verbose kind, I guess I will put in a summary at the top leaving the original post below for everyone to read all the little details. Essentially the summary is that I (and many other core developers) agree that HEAD/trunk in its current form was stalling future development on PHP. Jani indirectly jump started the discussion of moving this stumbling block out of the way by essentially doing two commits that violate the most fundamental rules of PHP development (and common sense courtesy) we have. I am worried that this will lead to confusion in the user base and other seem to think that the "ends justify the means". I also think that we need clearer processes to make it easier for new developers to have a clear path to follow in order to get things done in PHP.

Full story:
So this all requires a bit of background. I still remember my first contact with a PHP core developer. I do not quite remember the year, but it was quite some time ago. Anyway Jani was great, we filed a bug report on the imap extension. He fixed the bug in no time. IIRC we also ended up sharing a room at the second IPC in Frankfurt I attended. I think only a few years later I realized that Jani is the same guy a lot of people were complaining as being rude. But I guess few of these people realize how much time Jani has spend on verifying bug reports and what a tedious job this is, especially since most bug reports are quite low on the actual relevant details and come with a "fix my code for me, now!" attitude. In other words, I get along fine with Jani and I have great respect for his contributions to PHP.

Next piece of background. I am also one in the long list of people that has made a fool of himself by predicting a release of PHP6 in about 18 to 24 months (quite a few people have given this prediction over the past 3-4 years I guess). I have also been one of the people that has tried to motivated people at various times to finish those last 2% that seem to be missing to complete PHP6 in terms of functionality. As such I have opposed a PHP 5.4 because I felt its time to focus on finish up PHP 6 which we have promised people for so long. After releasing 5.3.0 I was hoping things would happen. But last weekend I came to the realization that we have waited long enough. That even if PHP 6 would be unicode bliss (at least in terms of features, probably not in terms of performance), the fact of the matter is that in all of the many years nobody put in the time to finish it. This imho is an indirect proof that the approach taken apparently does not hold enough merit to the world in general. Furthermore looking at internals since last summer it has been more dead than ever: PHP 6 aka HEAD aka trunk had become such a motivation killer that nothing was happening.

At the same time I knew that suggesting to move trunk to a branch and copying 5_3 to trunk would cause a lot of confusion. Not only among those reading internals, but also that this would quickly make it to the news sites of the world. Call it politics, marketing or just an unwillingness to cause thousands (millions?) of PHP developers distress and uncertainty, but I figured it would be better to propose this with a semi solid plan and giving a number of PHP core developers the heads up that I will bring this to the list, so that they also could prepare themselves. So I started talking to people offlist, either in person, via phone, via IRC/skype or via email with the full intention of going to the list no later than the end of this month, ideally sooner rather than later. I should also note, I do not code C, I also do not consider myself a unicode expert. So if I wanted to present a plan, I obviously needed to talk to people to get my facts straight.

Anyways, this week Jani decided to commit a patch. I guess I didn't mention one more piece of background. Jani had asked to get this patch into PHP 5.3 during the pre alpha stage, but at the time Johannes and I (I was co-RM back then) felt that the patch hadn't been tested enough in HEAD and that while we knew the patch fixes several bugs, we felt the risk of introducing new bugs was too high, especially since Michael who wrote the original patch for HEAD was not always around to fix things. Johannes had tried to get the patch into 5.3 six months earlier, but at the time nobody had time to do the work. So we decided to stick with the known bugs, instead of fixing them and risking new bugs in a very core component of PHP close to going alpha. So basically Jani committed a huge patch into a stable branch, without talking to anyone about this, despite knewing full well that the RM had specifically vetoed this patch in principle. Furthermore the patch from my understanding even breaks the ABI which makes the patch even more a no go.

Now I was quite surprised when I saw this patch and I at first got confused why Johannes would allow this patch in now only to find out that he didn't. Like several others I told Jani that he needs to revert this patch, but I then did the fatal mistake of expressing sympathy for Jani by saying that he probably was acting out because of frustration over PHP 6 been stalled as the patch in question was already applied there. Now instead of reverting the patch Jani decided to take things a step further now and simply created a PHP 5_4 branch, despite the fact that during the last discussion over the creation of 5_4 the consensus was to instead focus on PHP 6. Of course there was little focus on PHP 6, which is why I (and many others) also wanted to drop the current approach. If the next version should be 5.4 or 6.0 is of course not a trivial decision to make. For one we had already decided on a lengthy list of [stuff we wanted to remove from PHP for PHP 6, and even if we were to drop unicode from PHP 6, chances were we would stick to the original plan for all other things. Obviously we can however not start stripping these features in a 5.4.

Anyway, the good news in all of this was that people were starting to get excited about the future of PHP again. But what irritated me was that apparently a fan club for Jani's actions was forming. It seemed that people were saying he was providing a "shock to the system" that revived core. I do not have reason to believe that it would have been less successful to revive internals without basically pissing all over an RM decision and then following this up by pissing over all sorts of unwritten rules that it's not a lone wolf call to create a branch with the name of a possible future PHP version. Worse yet, if this even gets you a fan club, it means that the already insanely maddening work of an RM just got that much harder. Furthermore Jani was happily committing away into the 5_4 branch, while others were still working on 5_3. Why should they suddenly be obligated to merge stuff into 5_4 because of Jani's shooting from the hip decision? Shouldn't the point in time for such a branch be a bit more consciously decided? Calls to get the branch removed were answered that its all good and sooner or later the 5_4 branch will be renamed into trunk anyway, even though there was still no clear decision.

I am sorry, I might be a rule loving German but WTF?!?!?!?! At this point I cannot even try to put into words the level of disappointment. Of course most of us do the bulk of the work on PHP in our spare time, but we do have to have a sense of responsibility to the world out there, with many people depending their professional life's on PHP, something I assume we welcome, and we are toying with the image of PHP here. We are also toying with the position of the RM here, one of the few roles we have in PHP, which is critical to getting at least a tiny bit of structure into the development process. PHP is simply too big to go without any structure at all. So to me the only thing to do at this point was to slam a bit on the breaks. For one I asked that Jani's commit karma be revoked until we sort out the situation. This would have given us the opportunity to communicate to the world at large: "Sorry, someone jumped the gun, do expect some real news to be communicated soon." Instead we have news (heise is probably the most important german speaking tech site) sites and the twitter-verse announcing the creation of 5_4 and the death of native unicode inside the engine. But the cheerleading went on and any criticism of Jani was deemed "bashing". Again WTF?!?!?!

I should note one more thing. A lot of people got pissed off by the fact that I decided to first talk to people offlist. This includes many people who I have not yet contacted and a few I did contact. I realize that it's not ideal to do so. I hope nobody is implying I might be complaining about Jani because I was hoping for a moment of fame singlehandedly reviving PHP development. I also realize that going to the list directly could not have been worse than what Jani has created now. I also realize that with all the unwritten rules and power structures in PHP its hard for new guys to get the things happening they want (the fact that traits is still not committed to trunk is a prime example of this very problematic situation). In that light to many Jani's stepping over all rules and processes might seem empowering to the people that are not part of the "inner circle" of core PHP developers. I think thats very short sighted. Again I am German, so I have a tendency to trust rules a lot, but I feel the more rules and processes the actually write down and follow, the more of a chance new people will have in getting "shit done" without turning the project's principles to "shit" like what Jani did with his commits the past two days. So instead of cheering on Jani to continue pissing all over the very few rules we do have, I feel people should more work towards identifying some more rules we can agree on that will ensure that new guys have a clearer processes to getting things into core.

I hope that with this blog post I have clarified my position a bit more and I hope that I have convinced some of you that thinking first rather than just shooting from the hip is the better approach when it comes to dealing with such large sweeping decisions like reconsidering the branch into which so much work was pored into and on which so many promises for the future of PHP were based. After taking a bit of time to playing some "laser frisbee" and listening to soothing music I am now again a bit hopeful that we can bring some dearly needed structure into the process to determining a realistic plan for the future of PHP that best serves our large user base.

Sorry, your text is very hard to read. Please have a thought about Simplicity even in Blogposts.

Sandra doesn't know how to read? lol I managed to read it just fine.

Well I do admit that I am usually a bit too verbose in my blog posts and that as a result it might be a bit hard to follow them. Especially this post in particular is very long and might require a lot of knowledge over the history of PHP. I tried to put in the most important pieces into this blog post, which is the main reason why the post ended up being so long. A vicious circle. I hope the addition of the summary at the top will help people understand the main areas of focus in this post.

Great post, I think it's time to do something about create a process to do things in PHP, like you say, PHP now is taken serious in the enterprise business and this kind of things is just bad for PHP (too much chaos), now it's time to make something like java's jcp or python's pep process, you are right, we need more rules, PHP has a lot of "wtfs" in the language cause all the process to make things in the PHP core is just a joke.
Nice to see somebody that wants to do things better inside PHP, some other dynamic languages do things better cause they have a process or even a "Benevolent Dictator for Life", maybe we can get a "Benevolent Dictator for Life", maybe you ;).

Cheers.

Didn't know the backround until now. But from a develoeprs view sometimes it's ok to drop a bad trunk in favour of something else/ a new start.
Since i do not read much internals, alll that is a secret to me.
As far as i am concerned on the heise topic: You guys should't take that too serious. It's just some editors, catching up with the latest infos from the web and in heises case making it worse, just feeding it to a bunch of trolls creating useless content for them by (happily) getting them stuff to troll over.
Let's lean back: 5.3 turns out to be a quality product, 5.3.2 went to my hd today and seems to provide a even better php.
But i can understand your point on loose cannon devs on the other hand. Someone creating facts by SVN actions is a real danger to any pieceof software, no matter how highly skilled this person thinks he is.

The minutiae of this are way beyond my level but I get the main point: Somebody broke the rules and potentially created mayhem by breaking a backwards compatibility protocol and potentially introducing new bugs into a critical part of the package.

The question is how conservative must the rules be to avoid people crippling themselves by clinging to outdated tools and their resultant methodologies just because "they work," vs. how can we move forward at a reasonable speed while dragging all this baggage.

Thank you for your long explanation! This clarifies the situation and helps to understand whats behind the doors (of PHP).

This Jani sounds likes a wrong-un

Get rid of him - he's dispensable. No one person is bigger than a project

Well I should clarify. I tried my best to give an objective account of the situation. But it should be clear from the "WTF??!?" stuff that I am somewhat emotional about this topic. Maybe other core developers will publish their observations. Johannes for example see us a fit further already in the sense that he feels we have already made a definitive decision to use 5.3 as the basis for trunk. Since he posted his blog post several other developers have come out in favor of this and I think its likely what will happen, but I would see some more clear votes on internals before I see it as definitive.