Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:79324
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.218.41 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <547B6B54.5020009@gmail.com>
References: <547AD8D8.9060603@fedoraproject.org>
	<CAFMT4NqRag55P0bx+aD1_-3zAbLvdxsB8NHdzVUHYP6ssnwJ-Q@mail.gmail.com>
	<547B5C93.7050001@fedoraproject.org>
	<547B6B54.5020009@gmail.com>
Date: Sun, 30 Nov 2014 20:33:31 +0100
Message-ID: <CAH-PCH7P8eJ=Cm--EV9HM+gVmeubSu+QqxV-3VNmtGTJ-Foo+g@mail.gmail.com>
To: Rowan Collins <rowan.collins@gmail.com>
Cc: PHP Internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=001a113ada30acd0ff05091891ec
Subject: Re: [PHP-DEV] Feature: use Posix ACL for FPM socket
From: tyra3l@gmail.com (Ferenc Kovacs)

--001a113ada30acd0ff05091891ec
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Sun, Nov 30, 2014 at 8:09 PM, Rowan Collins <rowan.collins@gmail.com>
wrote:

> 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 hav=
e
> 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. Th=
e
> crucial paragraph is this:
>
> > No feature addition after final x.y.0 release (or x.0.0). Self containe=
d
> features or new SAPIs could be carefully considered on a case by case bas=
is.
>
> 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


this is also my interpretation(that is should be of a case-by-case approval
process instead of a RMs can veto if they really want), but I seem to be
the minority on this side.
having said that, I would be fine having this one in 5.6.x.

--=20
Ferenc Kov=C3=A1cs
@Tyr43l - http://tyrael.hu

--001a113ada30acd0ff05091891ec--