Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:79337
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.192.50 as permitted sender)
MIME-Version: 1.0
Sender: julienpauli@gmail.com
In-Reply-To: <CAH-PCH7P8eJ=Cm--EV9HM+gVmeubSu+QqxV-3VNmtGTJ-Foo+g@mail.gmail.com>
References: <547AD8D8.9060603@fedoraproject.org> <CAFMT4NqRag55P0bx+aD1_-3zAbLvdxsB8NHdzVUHYP6ssnwJ-Q@mail.gmail.com>
 <547B5C93.7050001@fedoraproject.org> <547B6B54.5020009@gmail.com> <CAH-PCH7P8eJ=Cm--EV9HM+gVmeubSu+QqxV-3VNmtGTJ-Foo+g@mail.gmail.com>
Date: Mon, 1 Dec 2014 13:34:15 +0100
Message-ID: <CAMUwpuSh9QaXTZy-DSUvV71Red-QkHrTdGvfLfEcZ2JDACHp+w@mail.gmail.com>
To: Ferenc Kovacs <tyra3l@gmail.com>
Cc: Rowan Collins <rowan.collins@gmail.com>, PHP Internals <internals@lists.php.net>
Content-Type: text/plain; charset=UTF-8
Subject: Re: [PHP-DEV] Feature: use Posix ACL for FPM socket
From: jpauli@php.net (Julien Pauli)

On Sun, Nov 30, 2014 at 8:33 PM, Ferenc Kovacs <tyra3l@gmail.com> wrote:
> 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 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
>
>
> 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.

For me, this feature is self contained, and even benefit from an
activation switch (--with-fpm-acl) , saying it will not change the
codebase if not activated. So it may be included in 5.6

However, I agree that it's bad to have : "from 5.6.Z , you may use
FooBar feature", better to have "from 5.6".
Having patches introducing new features in revision versions is hard
to remember and bad for versionning

Julien.P