Re: Feature: use Posix ACL for FPM socket
| From: | Ferenc Kovacs | Date: | Sun, 30 Nov 2014 19:33:31 +0000 |
| Subject: | Re: Feature: use Posix ACL for FPM socket | ||
| References: | 1 2 3 4 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-79324@lists.php.net to get a copy of this message | ||
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.
--
Ferenc Kovács
@Tyr43l - http://tyrael.hu