Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:44489
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 72.14.220.157 as permitted sender)
DomainKey-Status: bad
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=AVT1bhpCcLaNxS3pEmc91N8CFY/u7LlsiiRBy5yGctU6P9vkgQcP4AH4WFkjNpLn78
         dQKGeQp3cMo3EiVmnF4DDODQwr7R7Q6qcfMuOMqkdrOphi7CI2u7HcgvVk2KVS177yKs
         yhfsJKNfskI23Nygndt2ULc70b8PRVpeR6g+s=
MIME-Version: 1.0
In-Reply-To: <B47081C9-6828-4367-8F0D-91B1701D5D51@macvicar.net>
References: <9A46F4B8-E64A-4C3C-B2A5-FC354A3EB71D@pooteeweet.org>
	 <0C2F23C2-D188-4938-B44C-4ED166B934CE@macvicar.net>
	 <fe05d1540906261126k2d6f12fenf5b00b44044614d4@mail.gmail.com>
	 <EAD7D00F-5B9F-4D43-9614-589F5BE039D8@pooteeweet.org>
	 <DFD95E35-FEA2-4EBE-84A9-6A5FDA85CF53@macvicar.net>
	 <fe05d1540906261312w79df6b9cp97e41e5b68e740a0@mail.gmail.com>
	 <B47081C9-6828-4367-8F0D-91B1701D5D51@macvicar.net>
Date: Fri, 26 Jun 2009 22:47:09 +0200
Message-ID: <fe05d1540906261347r7826335eg52708ac2a2213d94@mail.gmail.com>
To: Scott MacVicar <scott@macvicar.net>
Cc: Lukas Kahwe Smith <mls@pooteeweet.org>, PHP internals <internals@lists.php.net>
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)

this process is known and we already said that we have to change the
way we do it after 5.3.0.

On Fri, Jun 26, 2009 at 10:35 PM, Scott MacVicar<scott@macvicar.net> wrote:
> I *completely* agree with making sure 5.3.0 is stable and stopping extra
> things sneaking their way in. I just don't like the way that it is being
> done.
>
> If the release is tagged and built, then why continue with the freeze? Why
> not open it up for bug fixes towards 5.3.1?
>
> If the reason that you're about to be given is, we might find something
> critical and need to re-roll 5.3.0 then branch from the tag you've created,
> fix what's needed and re-tag. Even though CVS sucks it does allow this.
>
> This is the way the Mozilla project has done it for years, following their
> example we'd just create a PHP_5_3_RELBRANCH and work from that. The RMs are
> the only ones that get to decide what goes in after the freeze.
>
> https://wiki.mozilla.org/SeaMonkey:Release_Process
>
> Scott
>
>
> On 26 Jun 2009, at 21:12, Pierre Joye wrote:
>
>> 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<scott@macvicar.net> wrote:
>>>
>>> On 26 Jun 2009, at 19:59, Lukas Kahwe Smith wrote:
>>>>
>>>> On 26.06.2009, at 20:26, Pierre Joye <pierre.php@gmail.com> wrote:
>>>>
>>>>> On Fri, Jun 26, 2009 at 7:30 PM, Scott MacVicar<scott@macvicar.net>
>>>>> 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.
>



-- 
Pierre

http://blog.thepimp.net | http://www.libgd.org