Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:85641
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.214.172 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <030a01d06c98$e84725b0$b8d57110$@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>
Date: Wed, 1 Apr 2015 19:12:23 +0200
Message-ID: <CAH-PCH4PDmu7JM4j01M0K9TtPeCBY3jf5LzRJS2prvd_mZEwaQ@mail.gmail.com>
To: francois@php.net
Cc: Dennis Birkholz <dennis@birkholz.biz>, PHP Internals <internals@lists.php.net>, 
	Stanislav Malyshev <stas@php.net>
Content-Type: multipart/alternative; boundary=089e01293f0e9d6cbb0512acd162
Subject: Re: [PHP-DEV] What's our official stance on small self-contained
 additions in a micro version
From: tyra3l@gmail.com (Ferenc Kovacs)

--089e01293f0e9d6cbb0512acd162
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Wed, Apr 1, 2015 at 6:28 PM, Fran=C3=A7ois Laupretre <francois@php.net> =
wrote:

> > De : Ferenc Kovacs [mailto:tyra3l@gmail.com]
> >
> > I could accept any decision between holding off new features until next
> > minor/major and allowing features explicitly without going through an
> RFC, but I
> > want to have an explicit definition on what is allowed and how should
> the case-
> > by-case process work.
>
> 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 o=
f
> "should" but it is quite clear.
>

I see your point, but the consensus/status quo(based on past mailing list
discussion and( is/was that not everything requires an RFC.


>
> 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 n=
ew
> features without demanding an approved RFC. If everyone respects the rule=
s,
> 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.
>

again, I'm fine with changing the current status quo, but we can't pretend
that this was always the consensus when we were doing otherwise and >95% of
the people seemed to be okay with it (I had a couple of threads in the past
years where I tried to clarify a couple of things about the voting and
releaseprocess rfcs, but nothing really come out of it).


>
> 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.
>

As I mentioned this wasn't something without precedence, but seeing how
Derick(ext/date lead author/maintainer) was explicitly against this change,
and there were no favorable response from the list I tend to agree with the
revert.
For the record this was merged by Stas:
http://git.php.net/?p=3Dphp-src.git;a=3Dcommitdiff;h=3Dcc2fd00942d599753261=
66be70cd36da85a681d3


--=20
Ferenc Kov=C3=A1cs
@Tyr43l - http://tyrael.hu

--089e01293f0e9d6cbb0512acd162--