On 2010-11-23, Derick Rethans <der...@php.net> wrote: > On Tue, 23 Nov 2010, Ferenc Kovacs wrote: > > > All the rest you write in the RFC is basically already as we do it. > > > > yeah, maybe, but they aren't written down, accepted and well-known rules, so > > you can forgot/misunderstand/bend them. :/ > > And I don't think that is a bad thing. It's good to be able to be > flexible.
A good artist is capable of great flexibility within the constraints of their medium. In the case of software releases, you can still have greate flexibility even with an existing release process. In many ways, having the process defined helps bring about creative solutions -- "if I want to get this in time for the release, what solution will work best?" I used to love the ad hoc nature of "we'll release when it's ready." However, having done quite a number of scheduled releases, I've found that: * Predictability motivates developers. "Release is in 3 months? Okay, let's get rolling on this!" * Knowing when the next release is coming also means that developers are more comfortable if they're unable to make the deadline. "I can't do it by this release, but I should have no trouble making the next." * Less stressful for release managers. If the code isn't ready by the deadline, it's not merged to the branch, plain and simple. The status quo works great for those whom it serves. For everyone else, it stinks. There's no transparency, which leads to disenfranchisement. -- Matthew Weier O'Phinney Project Lead | matt...@zend.com Zend Framework | http://framework.zend.com/ PGP key: http://framework.zend.com/zf-matthew-pgp-key.asc -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
