Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:46322 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 52046 invoked from network); 7 Dec 2009 14:59:50 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 7 Dec 2009 14:59:50 -0000 Authentication-Results: pb1.pair.com header.from=ilia@prohost.org; sender-id=unknown Authentication-Results: pb1.pair.com smtp.mail=ilia@prohost.org; spf=permerror; sender-id=unknown Received-SPF: error (pb1.pair.com: domain prohost.org from 209.85.212.195 cause and error) X-PHP-List-Original-Sender: ilia@prohost.org X-Host-Fingerprint: 209.85.212.195 mail-vw0-f195.google.com Received: from [209.85.212.195] ([209.85.212.195:44025] helo=mail-vw0-f195.google.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 42/7C-31234-4681D1B4 for ; Mon, 07 Dec 2009 09:59:50 -0500 Received: by vws33 with SMTP id 33so1703451vws.27 for ; Mon, 07 Dec 2009 06:59:46 -0800 (PST) Received: by 10.220.127.74 with SMTP id f10mr8267285vcs.83.1260197985907; Mon, 07 Dec 2009 06:59:45 -0800 (PST) Received: from paulalaptop.centah.local (dev.centah.com [67.215.199.37]) by mx.google.com with ESMTPS id 20sm12541196vws.4.2009.12.07.06.59.43 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 07 Dec 2009 06:59:45 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii In-Reply-To: Date: Mon, 7 Dec 2009 09:59:42 -0500 Cc: =?iso-8859-1?Q?Johannes_Schl=FCter?= , internals Content-Transfer-Encoding: quoted-printable Message-ID: <840804B4-91AF-47AE-895B-29030EF4DC5F@prohost.org> References: <1260193069.1383.33.camel@guybrush> <306DF528-C204-4B9E-8285-27D9FFDE11E5@prohost.org> <4478B8CF-9446-472E-BC40-C0B18EBFA1B8@prohost.org> To: Pierre Joye X-Mailer: Apple Mail (2.1077) Subject: Re: [PHP-DEV] Towards 5.3.2 From: ilia@prohost.org (Ilia Alshanetsky) Pierre, It has everything to do with the separate branch. Our current approach, = (as flawed as it maybe) ensures patches are not missed, since there is = no separate branch, so patches go into the release tree. With the new = approach if something is not merged it is not part of the release. This = also makes it confusing for the users, since the dev fixing the bug = indicates on the bug tracker the issue was resolved, and will be part of = the next release. And then the next release comes out and the bug/issue = is still there... On 2009-12-07, at 9:55 AM, Pierre Joye wrote: > 2009/12/7 Ilia Alshanetsky : >=20 >> The NEWS file would tell me why patches were not merged? Also the = news file does not contain entries about many fixes that don't have = corresponding bug # attached to them. >> As I recall the 5.3.1 NEWS entry were merged back to the PHP_5_3 6 = days after the release by you ;-). >=20 > Ok, so what you are arguing about is that you don't know why something > was not merged. That's something we like to improve but it has nothing > to do with the extra branch, absolutely nothing. >=20 > Cheers, > --=20 > Pierre >=20 > http://blog.thepimp.net | http://www.libgd.org