Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:79323
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.212.178 as permitted sender)
Message-ID: <547B6B54.5020009@gmail.com>
Date: Sun, 30 Nov 2014 19:09:08 +0000
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: internals@lists.php.net
References: <547AD8D8.9060603@fedoraproject.org> <CAFMT4NqRag55P0bx+aD1_-3zAbLvdxsB8NHdzVUHYP6ssnwJ-Q@mail.gmail.com> <547B5C93.7050001@fedoraproject.org>
In-Reply-To: <547B5C93.7050001@fedoraproject.org>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] Feature: use Posix ACL for FPM socket
From: rowan.collins@gmail.com (Rowan Collins)

On 30/11/2014 18:06, Remi Collet wrote:
>> >However, I think we should stop including features in our patch
>> >releases. I've heard a few others express similar sentiment, but
>> >it may have been more targeted at what we are allowing for "bug
>> >fixes" in patch releases. Anyway, that's my input.
> Yes, I'm one wanting to reduce new feature in stable branch...
>
> This is the reason why I propose this feature for 5.6 (not 5.5) and
> with a new option to not change default build.

But that's still technically introducing a feature in a patch release.

 From a documentation point of view, it's a lot tidier if we only ever 
have to say "since PHP x.y" rather than "since x.y.z", and as you say, 
there's always a risk. I don't know much about this case, but let's say 
a mistake allowed a misconfigured build to apply an inadvertently wide 
ACL; having that emerge in a patch release could mean downstream 
maintainers losing faith in the official releases, and make everyone's 
lives harder.

Part of the stated aim of the release process RFC [1] was to "reduce the 
time to get new features in a release", and the solution to that was to 
guarantee a release every year, so that there's never more than a few 
months to wait, while simultaneously having clean, safe, patch builds. 
The crucial paragraph is this:

 > No feature addition after final x.y.0 release (or x.0.0). Self 
contained features or new SAPIs could be carefully considered on a case 
by case basis.

That wording implies - in my opinion - that the burden of argument 
should be on the feature's sponsor for why an exception should be made, 
but there's a temptation to shoot for inclusion everywhere and see if 
the RM challenges it.

[1] https://wiki.php.net/rfc/releaseprocess

-- 
Rowan Collins
[IMSoP]