2013/4/3 Laruence <[email protected]>:
> On Wed, Apr 3, 2013 at 4:22 PM, Stas Malyshev <[email protected]>wrote:
>
>> Hi!
>>
>> > Added new constant CURL_WRAPPERS_ENABLE in (include 5.4)
>> >
>> https://github.com/php/php-src/commit/d7f709a032a40cb475042b43db07a4698a2488b7
>>
>> 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..
>
> 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.
>
> 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 okey
> to commit.
>
> however, you are right, it's not a long time, so if objections becomes
> strong, I can revert it.
I think my argument against adding the constant is at least just as
strong as adding it. I agree we shouldn't go RFC/vote etc, over one
single constant but I think we can all agree on the fact that we
shouldn't try to add hacks to fix usage of an experimental feature
(which is essentially what this constant is).
We need more consistency, than inconsistencies.
--
regards,
Kalle Sommer Nielsen
[email protected]