Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:46326 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 58798 invoked from network); 7 Dec 2009 15:11:01 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 7 Dec 2009 15:11:01 -0000 X-Host-Fingerprint: 217.114.211.68 unknown Date: Mon, 07 Dec 2009 10:11:00 -0500 Received: from [217.114.211.68] ([217.114.211.68:25278] helo=localhost.localdomain) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 95/FD-31234-40B1D1B4 for ; Mon, 07 Dec 2009 10:11:00 -0500 To: internals@lists.php.net References: <1260193069.1383.33.camel@guybrush> User-Agent: slrn/0.9.9p1 (SunOS) Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: X-Posted-By: 217.114.211.68 Subject: Re: [PHP-DEV] Towards 5.3.2 From: sn_@gmx.net (David Soria Parra) 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 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 : >>> 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 >