Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:44487 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 41202 invoked from network); 26 Jun 2009 20:12:31 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 26 Jun 2009 20:12:31 -0000 Authentication-Results: pb1.pair.com header.from=pierre.php@gmail.com; sender-id=pass; domainkeys=bad Authentication-Results: pb1.pair.com smtp.mail=pierre.php@gmail.com; spf=pass; sender-id=pass Received-SPF: pass (pb1.pair.com: domain gmail.com designates 72.14.220.155 as permitted sender) DomainKey-Status: bad X-DomainKeys: Ecelerity dk_validate implementing draft-delany-domainkeys-base-01 X-PHP-List-Original-Sender: pierre.php@gmail.com X-Host-Fingerprint: 72.14.220.155 fg-out-1718.google.com Received: from [72.14.220.155] ([72.14.220.155:11343] helo=fg-out-1718.google.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id F6/26-08868-EAB254A4 for ; Fri, 26 Jun 2009 16:12:31 -0400 Received: by fg-out-1718.google.com with SMTP id e12so730890fga.0 for ; Fri, 26 Jun 2009 13:12:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=WkDPbWvI44/ZVugagOkWEdxPnYv/mbHOU8wrUkZC2iM=; b=ALjcV7/ZRxawQIfdJ2amJWKnOYifsen29efRErw4VIq3H+cMl2AOZgOxvf1jVKdAAy HqRXDScUIgqggPtUr7JxSM31cYwTlbeCkJYdAP5mPf5ulyG7tXOTcaKrVpm6UnpWJKXX WJs1snLOvtm0WLDQCcvQJblGqJFUBdu6Jk1uY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=bAhCWk1NhNQ76On3MqS1MxnKl++7/1b/lIS7LorXVoDeLxF2abNpTWXmcLnWb/ripm cGy2P92Zi1jKXYiUZjdl1agMeeCfwEskgJGg9pQ6orrNroXYE2qbOpiM1bq6+JWEeLyg Bif3TuPLzFc62zx44Fh/GJqPJyPoQd4eb/7cE= MIME-Version: 1.0 Received: by 10.86.4.14 with SMTP id 14mr4006163fgd.12.1246047147661; Fri, 26 Jun 2009 13:12:27 -0700 (PDT) In-Reply-To: References: <9A46F4B8-E64A-4C3C-B2A5-FC354A3EB71D@pooteeweet.org> <0C2F23C2-D188-4938-B44C-4ED166B934CE@macvicar.net> Date: Fri, 26 Jun 2009 22:12:27 +0200 Message-ID: To: Scott MacVicar Cc: Lukas Kahwe Smith , PHP internals Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [PHP-DEV] post 5.3.0 development From: pierre.php@gmail.com (Pierre Joye) you totally misunderstood the mail. The freeze is about the days between now and the release itself on Tuesday (monday evening actually). That's perfectly valid. The idea then is to allow only bug fixes in 5.3.1, and only bug fixes. What's wrong with that? -- Pierre On Fri, Jun 26, 2009 at 9:26 PM, Scott MacVicar wrote: > On 26 Jun 2009, at 19:59, Lukas Kahwe Smith wrote: >> >> On 26.06.2009, at 20:26, Pierre Joye wrote: >> >>> On Fri, Jun 26, 2009 at 7:30 PM, Scott MacVicar >>> wrote: >>>> >>>> On 26 Jun 2009, at 16:26, Lukas Kahwe Smith wrote: >>>> >>>>> Aloha, >>>>> >>>>> So the last fix is just being prepared for a commit and so we will be >>>>> tagging 5.3.0 soon. >>>>> >>>>> We would like to up hold the commit freeze until 5.3.0 is announced >>>>> next >>>>> Tuesday. >>>>> >>>> >>>> This freeze that you guys have implemented is frustrating, just branch >>>> 5_3 >>>> into a release branch and Johannes can take selective fixes from 5_3 as >>>> needed. >>>> >>>> We all know your reasons for the freeze and agree with it but holding up >>>> regular development is a PITA. >>> >>> It is not holding up development. It is about getting a viable release >>> cycle and to give us the minimum safety to release 5.3.1 in a >>> reasonable time frame. Please explain me what's wrong to allow only >>> bug fixes for this phase? >>> >>> Also please note that we have HEAD for all the developments and new >>> features. >> >> Exactly. >> I will do my best to track things that need to be merged. Best is to note >> if something needs to be merged. >> >> But if you all feel it's such a huge burden then you can of course insist >> on putting the burden on the RMs. The fact of the matter is that our current >> infrastructure is not fit for providing both sides with an efficient >> solution. >> > > If we're freezing some more after this release for the SVN conversion then > we could have a pretty cold branch for another week or so. > > As I've already said, I agree with only allow verified bug fixes by Johannes > into 5.3.0. it's this extra bureaucracy that is getting added on top that's > sucking hard. > > I don't want to leave it up to someone else to merge it into 5.3, I should > be doing it myself. It's possible that things could get accidentally missed > wen someone else is applying it. > > Scott > -- Pierre http://blog.thepimp.net | http://www.libgd.org