A little more than a half year ago I announced my retirement from PHP core. Since then I have directed my focus elsewhere like Symfony2 and not the CMF project. I do not regret the decision. The main reason to step down was that it was just a too taxing up hill battle to move PHP towards a more open and transparent development process against the inner circle who preferred things to stay as they were back when PHP was by far not as popular or relied upon. This is what I had to say back then:

Through out all of the things I did my main vision was to increase transparency of what is happening within the project. Otherwise ideas get lost, new developers have no idea where to turn, end users have no idea of where things are heading etc. A key aspect here imho is that stuff like processes and discussions need to be documented. Obviously common sense stands above everything else, but I think its important to consciously deviate from the defined path instead of coming up with everything ad hoc. But PHP traditionally has had a bit of a paranoia that structured development would make the project boring and feel like work rather than fun. It always seemed weird to me that a language who's main feature was low barrier to entrance was making participation in the development process so seemingly hard. Like the wiki idea was resisted for years because it was said that files in CVS were better, but imho its simply not convenient for developers and even less so for end users. Where is the fun in inconvenience?

Now it seems like I might have however misjudged the situation. Quite a number of core developers have teamed up to write up an RFC that addresses one of the biggest concerns that let me to my retirement: Creating a reliable, documented and transparent release process. Now this is no small task to get right, but I think this is a very good effort that is certainly a good basis for discussion. If this goes through it would be a huge win for PHP!

One major concern that raised right away was that its impossible to get people to commit to a release schedule if they do development in their spare time. A solution to that could be to instead just cherry pick finished features that are ready to go and accepted by the core team out of trunk. Again it was interjected that cherry picking is too difficult, but I think this approach holds a lot of merit and is worth exploring in more detail. It seems like with todays DVCS the technical problem of cherry-picking could be solved. Of course PHP just underwent a resource consuming migration to SVN, but moving to something else now should be easier to do now.

But lets go back to the concern that its unreasonable to expect developers to commit to a release cycle. I do not think this problem is all that big. For one even if one developer fails to hit the deadline, its just one feature among several. And in the worst case you can still push things by a few months. This is the approach PostgreSQL is taking, where they try to stick with a release schedule and push things around or simply drop a feature. Furthermore I believe that big features shouldn't depend on one developer to begin with. We have had and still have many key pieces of code that suffer from bus factor issues. While PHP is open source and there is a lot of peer review we still frequently end up with stuff that not enough people know about in order to efficiently maintain it. Or where there are so many personal preferences in the code that nobody really likes to take ownership. If we would move more towards a model where big features require 2 or more developers then the risk of a feature not making a release can be mitigated quite a bit.

Anyway, I hope that this RFC will be put into effect in one form or another! I totally agree with Matthew that the argument of inflexibility due to a process is a cop-out for the established developers. But again the fact of the matter is that PHP's role in the world has changed and that the current approach does not sufficiently address this.

Let us hope the RFC is agreed upon and adhered too. There are too many people just doing their own thing in core. We need to go through this short-term pain for this long-term gain.

Here's to hoping things will work out. The recent changes to strict type checking doesn't give me a lot of hope, but there seems to be some light at the end of that tunnel too. (http://news.php.net/php.internals/50485)

Personally I am not yet "there" with git. The command syntax just seems a bit random across the different tools, but it does seem quite powerful, though I hear Mercurial is a bit more consistent. At any rate for those wondering about the possibility to move to git to assist in branch management might find this post interesting.

Forgot to mention that I do see that at least git (and afaik also mercurial) do not offer anything that is as useful as svn:externals when it comes to modularize your repositories. But I kinda expect that some day someone will fix this, because I don't think there is something architectural that prevents this from being added to either git or mercurial.

there are some third party tools for handling externals dependencies in git:
http://www.rubyinside.com/giternal-easy-git-external-dependency-management-1322.html

mercurial has the subrepository feature, which is similar to the svn:externals

http://mercurial.selenic.com/wiki/Subrepository?action=show&redirect=subrepos

Tyrael

Bazaar is also a good contender. If I'm not mistaken, one of the aims of the next version is to implement "stacked branches" which I understand to be something like branches within branches. There are also a couple of plugins that are supposed to help with external dependencies.

@Lukas, @Tyrael: "git submodule --help" should help you along. I prefer using Git's built-in facilities to resorting to third-party add-ons.