We have had a few RFC's pass through internals ever since the creation of the wiki, but embarrassingly enough the very first one is still up in the air: Traits. Actually Stefan has since tweaked the proposal and in the latest version it includes an alternative approach called Grafts along with the original Traits idea, which is essentially language level delegation pattern support. I am absolutely sure that we will either see Traits or Grafts in the next non patch release of PHP (aka 5.4 or 6.0). So I rather want to see this patch make it into trunk sooner than later (btw since my last post the old 6.0 has been moved to a branch, Jani's 5.4 branch has been deleted and trunk has been recreated from 5.3 using the version 5.3.99-dev). However for that we need as many people as possible to review the RFC and better yet try out the patch. Right now Grafts look like the better approach to me. So either leave your comments on this blog, which I will then take into account when providing additional feedback on the mailinglist, send a mail to Stefan or participate in the discussion in the internals mailinglist.

Ages ago I created a Twitter account to get some free app. I figured some nobody was following me I didn't have to feel like a guilty spammer. For some odd obsession to honesty probably I did use my proper name and sooner or later people started following me despite me having only put out a single spam message. So on very few occasions I tried out tweeting (still feels weird using that word) since then, obviously I have never used it to get a free app again by spamming. Anyways I have now decided that for small blurps about technical stuff I will from now on use Twitter, thereby sparing my Facebook friends from such gibberish. In turn my developer friends on Facebook that do not care about what I have to say about Frisbee, DJing or politics can start removing me from Facebook. Actually I might just do this myself, because its FUCKING ANNOYING that so many people multi spam their status messages to Twitter and Facebook.

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.

At the recent Symfony Live conference I used the core team QA to address the audience to push for building new dedicated apps on top of general purpose frameworks like symfony and friends. More importantly those efforts should be released as early as possible in the development process as open source to ensure that others join instead of creating their own and then eventually releasing more and more redundant solutions. See the various symfony CMS solutions are an example of how wrong things can go. We now have several solutions whose architectural differences are either cosmetic or simply bad design decisions probably a result of trying to invent things in the small ecosystem of a company project team. So I was very happy to hear then that phpBB will adopt Symfony 2 for their next version. Hopefully this will become a role model for others.

I remember that back when I was co-RM for PHP 5.3 one of the very painful parts was the crying and moaning about the commit freezes we put into place while packaging up a new release. The reason being we were on CVS, if people kept committing while a release was being tested it would effectively prevent any sort of QA. Obviously we could have just tagged at the start of the QA process, but pretty much every time build fixes were necessary, if you then also throw in normal commits it wouldn't work at all. So we usually reserved about 2 days where no commits were allowed. Since there is no truly reliable way to inform people there would frequently be one or two commits still, but it was somewhat manageable. However it obviously made it quite annoying for people to work in this time interval. Either commits had to be delayed or someone had to remember to merge the change from HEAD once the commit freeze was over.