On Wed, Apr 3, 2013 at 10:37 AM, Laruence <larue...@php.net> wrote: > On Wed, Apr 3, 2013 at 4:22 PM, Stas Malyshev <smalys...@sugarcrm.com > >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
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=php-src.git;a=blob_plain;f=Zend/tests/bug55509.phpt;hb=HEAD 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 okey > 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 becomes > 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. -- Ferenc Kovács @Tyr43l - http://tyrael.hu
