Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:85642
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.212.172 as permitted sender)
Sender: Michael Wallner <mike.php.net@gmail.com>
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\))
In-Reply-To: <030a01d06c98$e84725b0$b8d57110$@php.net>
Date: Wed, 1 Apr 2015 19:15:42 +0200
Cc: Ferenc Kovacs <tyra3l@gmail.com>,
 Dennis Birkholz <dennis@birkholz.biz>,
 PHP Internals <internals@lists.php.net>
Content-Transfer-Encoding: quoted-printable
Message-ID: <4EECFE82-5457-4AD9-AEBD-1267D93863FA@php.net>
References: <CAH-PCH74+2-S2ySME1X5QW5rA9Jb5=1T+hJ3t1sxHiaTO31RJA@mail.gmail.com> <551BC7CF.3080309@birkholz.biz> <02f101d06c6e$3790c020$a6b24060$@php.net> <CAH-PCH7oeAPSR=MnXbx4pf6bOy_QON9exay_68rgbwxNQUqOAg@mail.gmail.com> <030a01d06c98$e84725b0$b8d57110$@php.net>
To: francois@php.net
Subject: Re: [PHP-DEV] What's our official stance on small self-contained additions in a micro version
From: mike@php.net (Michael Wallner)


> On 01 04 2015, at 18:28, Fran=C3=A7ois Laupretre <francois@php.net> =
wrote:
>=20
>> De : Ferenc Kovacs [mailto:tyra3l@gmail.com]
>>=20
>> I could accept any decision between holding off new features until =
next=20
>> minor/major and allowing features explicitly without going through an =
RFC, but I=20
>> want to have an explicit definition on what is allowed and how should =
the case-
>> by-case process work.
>=20
> The release process document is clear : "New features or additions to =
the core should go through the RFC process." (hopefully considering the =
'core' as the whole PHP distribution). It would be better using "must" =
instead of "should" but it is quite clear.
>=20
> So, providing "a room for exceptions on a case by case basis and only =
for small self-contained features and additions" does not mean that =
these features don't have to go through an RFC. There is nothing to add =
to the rules, we just need to have them enforced by people who currently =
merge new features without demanding an approved RFC. If everyone =
respects the rules, the 'case by case process' is clear, it means =
'approved through an RFC'. Only bug fixes with no side effect can be =
merged without an RFC.
>=20
> So, once again, as https://github.com/php/php-src/pull/1145 clearly =
did not follow the rules and was not approved in any way, I'm asking =
whoever merged it to revert the change and ask the author to go through =
an RFC.

It=E2=80=99s not a secret that I=E2=80=99m not a big fan of too much =
bureaucracy, we=E2=80=99re still humans that can discuss and argue =
without a formal RFC.
If anything develops to be controversial, let=E2=80=99s go through an =
RFC, if not, then fine and let them go ahead.