As Lukas pointed out, both approaches have flaws, but I think the new merging approach is much cleaner and prevents people from committing during a freeze.
Although the wiki might not be the perfect place to do things, I think the general approach is good. Core developers should know what's going on in the wiki, or at least don't complain. Cheers On 2009-12-07, Ilia Alshanetsky <i...@prohost.org> wrote: > Pierre, > > Actually patches were indeed missed, in fact we almost missed a security fix. > As far as the wiki goes, most people don't even know it exists, let alone > where to find it. Also, looking at the wiki there are a whole series of > patches that did not go in into 5.3.1, that there is little indication as to > why they didn't. > > > On 2009-12-07, at 8:46 AM, Pierre Joye wrote: > >> 2009/12/7 Ilia Alshanetsky <i...@prohost.org>: >>> Johannes, >>> >>> While the separate branch release for 5.3.1 was a worthwhile experiment, I >>> think it creates too much opportunity for missed patches and quite frankly >>> makes the whole release process confusing and complicated. My personal >>> preference would be that 5.3.2, not be released from a separate branch. >> >> It was actually the exact opposite. We did not miss patches once we >> were synced. The way we tracked the patches also let us actually >> define what must go in and what not, avoiding the classical last >> minute bad patches. The key to success is to do not let go months >> between a commit and its merge to the release branch, which was a real >> pain when we began 5.3.1. >> >> Cheers, >> -- >> Pierre >> >> http://blog.thepimp.net | http://www.libgd.org > -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
