Software Release Management is a Thankless Task
Software release management is a time consuming, thankless task. The release manager must balance the need for stability against the desire for every bug to be fixed and for great new features to be made available. Not all developers (or feature users) have the same idea of the goals of a release. The current PHP 5.2 release manager, Ilia Alshanetsky, has got each PHP release he's looked after into good shape. And luckily he's coped with any flak he's got.
Big software projects have well defined feature scope. They can enforce rules like "no feature checkins until you have fewer than X bugs". Or "no checkins unless your code test coverage number is greater than Y%". The responsibilities of feature area owners are clear and communication is constant.
It is harder to be so strict with PHP development. The open source community needs to keep its mostly volunteer developers enthused and appreciated. With its relatively fast pace of development there are constant small changes to the code base. This means there is a huge gray area about what is a bug versus a feature and about the priority of each change. It is harder to force tests or documentation to be created with each checkin.
Like with many things, developers always seems to leave things to that last minute. Ilia cleverly uses the announcement of the first release candidate (RC) as a wakeup call for all the last-minute features to get hurried up. However to me this means they don't get a full release cycle of testing, which is not ideal.
I'd like to see just a teency-weency bit more rigor in PHP releases. I don't want to see massive overheads of process and paperwork but just some tweaks (to start with). I'd like to see a well announced (possibly fixed, e.g. 1st day of every third month) date for the first RC of the next upcoming release. Yes, the date may change if planned big features slip but the new target can be published. When the first RC happens I'd like to see a lockdown of the code base enforced. Only fixes for logged bugs should be allowed to be merged and the release manager should pre-approve all code changes, taking decisions in that gray area of what is and isn't important.
We should also make better use of Lukas's release planning wiki or www.php.net to do scheduling.
I see these suggestions as reducing the confusion about the release process, minimizing (unintentional) bias about certain features or developers, and helping to improve the testing of features.
Hey, if your code change doesn't get in this release, there is always another one just around the corner.
