Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:85651
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.213.174 as permitted sender)
MIME-Version: 1.0
Sender: jakub.php@gmail.com
In-Reply-To: <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>
	<4EECFE82-5457-4AD9-AEBD-1267D93863FA@php.net>
Date: Wed, 1 Apr 2015 19:53:11 +0100
Message-ID: <CAEKnhAGYjoA2BbuMU7+nedR++FHZ105Rq0Sb+bXb2H94fh-xnA@mail.gmail.com>
To: Michael Wallner <mike@php.net>
Cc: francois@php.net, Ferenc Kovacs <tyra3l@gmail.com>, 
	Dennis Birkholz <dennis@birkholz.biz>, PHP Internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=001a113f2e3217c4ba0512ae3afb
Subject: Re: [PHP-DEV] What's our official stance on small self-contained
 additions in a micro version
From: bukka@php.net (Jakub Zelenka)

--001a113f2e3217c4ba0512ae3afb
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Hi,

On Wed, Apr 1, 2015 at 6:15 PM, Michael Wallner <mike@php.net> wrote:

>
> > On 01 04 2015, at 18:28, Fran=C3=A7ois Laupretre <francois@php.net> wro=
te:
> >
> >> De : Ferenc Kovacs [mailto:tyra3l@gmail.com]
> >>
> >> I could accept any decision between holding off new features until nex=
t
> >> 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 of "should" but it is quite clear.
> >
> > 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.
> >
> > 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 bure=
aucracy, 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.
>
>
I agree here. I think that we should definitely email to the internals
about any small addition (self-contained constant or function) and if there
are no objection and everyone agrees that it's a good idea, then I don't
think we need RFC.

Cheers

Jakub

--001a113f2e3217c4ba0512ae3afb--