Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:59618
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain oracle.com designates 141.146.126.227 as permitted sender)
Message-ID: <4F83BD74.6040406@oracle.com>
Date: Mon, 09 Apr 2012 21:56:20 -0700
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:11.0) Gecko/20120327 Thunderbird/11.0.1
MIME-Version: 1.0
To: Stas Malyshev <smalyshev@sugarcrm.com>
CC: PHP Internals <internals@lists.php.net>
References: <4F82878A.6030609@sugarcrm.com> <4F8356BA.1070904@oracle.com> <4F8360DA.5060604@sugarcrm.com>
In-Reply-To: <4F8360DA.5060604@sugarcrm.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] release process with git
From: christopher.jones@oracle.com (Christopher Jones)



On 4/9/12 3:21 PM, Stas Malyshev wrote:
> Hi!
>
>> I would like to see clarity on when fixes have been merged to the RC
>> branch (git emails are still a bit hard to grok).  It would help to
>> have early communication about fixes you have decided against so we
>> can argue their merits and so we don't assume you are planning to pick
>> them up.
>
> So this is the main point I want to change. There will be no fixes
> "decided for" and "decided against". Once RC1 is out, this is by default
> the release, and all the fixes since this point go into version X+1. The
> only exception - and I can't emphasize enough that I want it to be
> exception, not a usual occurrence - if we have a critical issue in RC1.
> So by default no fixes are rejected and no fixes are merged - once RC1
> is out, fixes are presumed to be in X+1 version. Unless you know this is
> a critical bug (meaning, there's absolutely no point releasing PHP with
> it as either one could not use it - e.g. it does not compile - or nobody
> in his sane mind would use it - e.g. remote security hole) there would
> be no point deciding or arguing about it.
> Again, this is a change from what we did before, not a big one, but as
> you can see it requires some mindset shift. I think it will improve our
> release process and will make us able to release quick and quality versions.

I think my main point still stands: if the git emails are too obscure to
follow, let us know what goes in via email to internals.

Do you want to bring the NEWS updating process into this discussion?

Chris

-- 
Email: christopher.jones@oracle.com
Tel:  +1 650 506 8630
Blog:  http://blogs.oracle.com/opal/