Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:86012
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.212.176 as permitted sender)
MIME-Version: 1.0
References: <CAMZ7uYexNm6Fy42GYCUW9MPnFWEun=JFOPPSa+-mxOPL7hpaGg@mail.gmail.com>
 <CAJW__o3WnrbZESJexF-tKgdw_br6MGYEtWKkweU_n1na5XOP=A@mail.gmail.com>
 <CACwt+JfB8vhZCtwCd4vH32Oan7e++75u3_E9TdYfgCoAHiViBg@mail.gmail.com>
 <CADajX4Ciwn3XaLnU_mWVgXfxiRVe4gDX=f1nhpbgdFXMfcfWOA@mail.gmail.com> <CAEZPtU6RroKFeqUSsX5+QG79Y8eCh94YVQXh3Q+Xy_+JCG41yA@mail.gmail.com>
In-Reply-To: <CAEZPtU6RroKFeqUSsX5+QG79Y8eCh94YVQXh3Q+Xy_+JCG41yA@mail.gmail.com>
Date: Wed, 29 Apr 2015 09:11:44 +0000
Message-ID: <CACwt+Jf0iy4+nt6_H7QpafvZMO3=pBH1xhRJxd7C+6ZWM6Cjzw@mail.gmail.com>
To: Pierre Joye <pierre.php@gmail.com>, Adam Harvey <aharvey@php.net>
Cc: Olivier Garcia <oliviergarcia@php.net>, PHP Internals <internals@lists.php.net>, 
	Kalle Sommer Nielsen <kalle@php.net>
Content-Type: multipart/alternative; boundary=089e013c673c3d57c00514d95e11
Subject: Re: [PHP-DEV] [RFC][VOTE] Improved Error Callback Mechanism
From: patrickallaert@php.net (Patrick ALLAERT)

--089e013c673c3d57c00514d95e11
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Le mer. 29 avr. 2015 =C3=A0 03:19, Pierre Joye <pierre.php@gmail.com> a =C3=
=A9crit :

> On Apr 29, 2015 5:38 AM, "Adam Harvey" <aharvey@php.net> wrote:
> >
> > On 28 April 2015 at 15:10, Patrick ALLAERT <patrickallaert@php.net>
> wrote:
> > > Le mar. 28 avr. 2015 =C3=A0 20:42, Kalle Sommer Nielsen <kalle@php.ne=
t> a
> =C3=A9crit :
> > >
> > >> I should probably have been faster at replying, but for PHP7 this is=
 a
> > >> no-go. I realize this is a pure internal change and have nothing to =
do
> > >> with userland, but as currently is, we are in feature freeze and it
> > >> creates a bad precedence between us as a team if we let this through
> > >> now, sorry!
> > >>
> > >
> > > "No go"? Isn't that a bit rough?
> > >
> > > That kind of change normally doesn't require an RFC at all. We did on=
e
> for
> > > documentation purpose instead of just a PR and a mail saying "ok for
> 7?".
> >
> > I don't agree. This adds nine API functions and a few hundred lines of
> > code: if you _had_ just committed this, I have no doubt that you'd
> > have people asking you to revert it pending an RFC and a vote. This
> > isn't a bug fix.
> >
> > Just because a feature is internal doesn't mean you can ignore the RFC
> > process. RFCs aren't just for language features: if they were,
> > Benjamin and I wouldn't have gone through the hassle of creating an
> > RFC for making gc_collect_cycles hookable a few months ago.
> >
> > > Refusing this because we actually did an RFC to *document* it goes in
> the
> > > opposite direction of encouraging people to create them.
> > >
> > > Isn't this just a documented "no brainer"?
> >
> > It's a good feature, the RFC is well written, and I have no doubt this
> > would be accepted for PHP 7.1. Indeed, it's something I could actually
> > make good use of in my day job.
> >
> > None of that is the point.
> >
> > We =E2=80=94 as a development community =E2=80=94 agreed to stop adding=
 new features
> > to PHP 7.0 on a certain date so that we could work on stabilising what
> > we had and getting it out the door this year. That date was over a
> > month ago.
>
> I see much more impacting change than this one. Yes it adds functions but
> not really new codes, I see as a refactoring.
>
Pierre is right, what you count as hundreds lines of new code is mostly
moving code from one file to another, function definitions, comments and
creation of macros to make the code more uniform/readable.

> > So, please, show respect for the people working hard on PHP 7.0 by not
> > trying to push something in against our agreed processes and making
> > more work for them.
>
> I would suggest then to end the white card given with the php7 rfc and
> consider to start releases and focus only on stabilization, not perf or
> related areas.
>
> Stabilization also includes APIs stabilization as we hopefully get more
> people work on getting exts ported.
>

--089e013c673c3d57c00514d95e11--