Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:66913
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.210.171 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CABBJUpfFeCwR_L59OsD7ZTtnL4=cNr6HW_boYneUFjKxjKVsqQ@mail.gmail.com>
References: <CABBJUpexRYZaXi10UobucCzJUXsLLK9avs+WspdSxyE4vDJ2rA@mail.gmail.com>
	<CADNQb0Uo0u2xCbR_joWKmwN9z+77nN-cLQ=Lcq2gpr0hf_A2qA@mail.gmail.com>
	<CABBJUpfx__wLqtG0w1SQzveggPiWubGLkPUJMFL+27cz3P_GyQ@mail.gmail.com>
	<CABBJUpcHuBT6schJm9gDe_tyz=Gvj53dNcs9UKbj2w040pCsiw@mail.gmail.com>
	<515BE6C2.7000801@sugarcrm.com>
	<CABBJUpfFeCwR_L59OsD7ZTtnL4=cNr6HW_boYneUFjKxjKVsqQ@mail.gmail.com>
Date: Wed, 3 Apr 2013 14:42:46 +0200
Message-ID: <CAH-PCH5Lr+yeiXwL0PjRb_M3ki6pPCLdMLCRMjqWE2GvM5H7kw@mail.gmail.com>
To: Laruence <laruence@php.net>
Cc: Stas Malyshev <smalyshev@sugarcrm.com>, PHP Internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=f46d0447f382e28b7404d9743050
Subject: Re: [PHP-DEV] Add a constant to reflect --with-curlwrappers
From: tyra3l@gmail.com (Ferenc Kovacs)

--f46d0447f382e28b7404d9743050
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Wed, Apr 3, 2013 at 10:37 AM, Laruence <laruence@php.net> wrote:

> On Wed, Apr 3, 2013 at 4:22 PM, Stas Malyshev <smalyshev@sugarcrm.com
> >wrote:
>
> > Hi!
> >
> > > Added new constant CURL_WRAPPERS_ENABLE  in (include 5.4)
> > >
> >
> https://github.com/php/php-src/commit/d7f709a032a40cb475042b43db07a4698a2=
488b7
> >
> > I must say the process of how it was done was not very good. Not only
> > there were no substantial discussion on adding this new thing in stable
> > version before the commit, the time between message announcing it and
> > asking if there are any objections and the commit was barely a day. It'=
s
> > not enough time at all to solicit feedback, and this change is not
> > really something urgent that needs to be committed ASAP. And it turns
> > out, there *are* objections. Could we be a little less quick with
> > commits into a stable version and give it some time when we're talking
> > about new things and not bugfixes?
> >
> Hey:
>     I have to say,  the objections only shows up after it happens


this happens more frequently if you don't give a chance to the people to
explain their problems before pushing the proposed changes.
this weekend and the monday was a national holiday for many
countries(Easter) so that was really bad timing.


>
>     but yes,  I am a little rush at this commit, that is because, you can
> see, the test script in ext/standard/tests/stream is depends on a ugly
> trick to skip . it make me very uncomfortable.
>

yeah, and that is what everybody else out there has to live with, so
nothing really changed apart the fact that you also bumped to the issue.
I'm not saying that the situation is ideal, but pushing changes to stable
(5.4) or feature frozen (5.5) branches without using the RFC system and
waiting for the feedback from the RMs is a bad thing to do.
We also have a couple of tests with even more uglier checks (see
http://git.php.net/?p=3Dphp-src.git;a=3Dblob_plain;f=3DZend/tests/bug55509.=
phpt;hb=3DHEAD
for
example), so I don't find that reason that convincing to throw our
processes out of the window.


>
>     I send the mail the day before yesterday,  and it's really not a big
> change (add a constant),  then no new feedback in a day,  I think it's ok=
ey
> to commit.
>

there were feedback from multiple people that it would be better to remove
the whole thing.
which you replied that it would be ok with you, then pushed your change.


>
>     however, you are right, it's not a long time, so if objections become=
s
> strong,  I can revert it.
>

this is exactly the kind of behavior why we changed from the commit first
then revert when people complaining to the current approach, where we try
to reach a concensus (via discussion on the mailing list or voting through
RFCs) before introducing a change.
the difference between the old and the current approach is that it switches
the burden of proof: instead of forcing others to prove that one's already
commited change is bad and should be reverted, the author has the burden
that his/her change is good enough to get in.
another recent example of the problem with the old approach was the
discussion about DateTimeImmutable: the majority agreed that it was a bad
decision to ship that as-is, but nobody dared to revert it.
hopefully Derick defused that situation, props for that.

ps: if we end up keeping the constant, please rename it to
CURL_WRAPPERS_ENABLED,
Kalle summed up pretty well the reasons.

--=20
Ferenc Kov=C3=A1cs
@Tyr43l - http://tyrael.hu

--f46d0447f382e28b7404d9743050--