Hi! > Why the hell should I start compromising with someone who thinks the > project, and by > extensions the contributors to the project small or large, don't behave > responsibly?!
Without getting into generalities about all contributors over all the project lifetime, I personally think what happened with this RFC falls short of the ideal RFC process as we'd like to see it happen in PHP. See below on that. I don't think it's useful to assign personal blame for anything here, but I think it may be useful to try and find the ways how to improve. > You say that this deprecation is an insult to our legacy users but you just > casually > insult (at least in my mind) the people who make this project live on. > Or are you just remicinent of ye olden days where core devs decided willy > nilly what > ever they want to do with the project? Because I though the whole idea > behind the RFC > process is to prevent this "closed club" of core dev who can decide > whatever they want. There are downsides to that. For example, people voting on RFCs without actually realizing the full extent of what they are voting for. Like voting for a change that will start dumping people's sources to the internet once implemented - without even realizing that would happen. I don't know, of course, how many of the people voting yes didn't realize that and how many did but did not care - but the following discussion shows that this definitely wasn't properly discussed because otherwise there wouldn't be any point in discussing it anew. And the solutions proposed so far negate at least half of proposed benefits from the RFC. So I am thinking - was what happened a good example of a good working process? Do we think the situation where we're talking about changing the approach days after the vote is how RFCs should work? I personally think that the fact that RFC was voted in without considering a critical BC issue and without even acknowledging it in the RFC shows we are way too hasty to introduce breaking changes and do not spend enough thought on evaluating their effects on existing users. It's very easy to ask people "do you hate short tags?" and get a resounding "yes". If you asked "do you want any old code that might use slightly older Smarty or some other not-recently-updated dependency suddenly spill its guts to the internet starting with 7.4?", the "yes" might be much less enthusiastic. But that question wasn't asked. And asking that question - the right question - is our job here. Which, in my opinion, in this case wasn't done properly - before voting on the RFC. Good that at least we're doing it after. > I was willing to compromise a lot but with all the respect I have for you > Zeev, your sheer arogance > just made any major compromise not a thing I want to pursue anymore. This phrasing looks suspiciously like you're basing your decisions in the matter not on technical merits and concerns about PHP project and its users, but on your personal grudges. I am certainly hoping this is just because of an unartful turn of phrase and you want to rephrase that in a way that does not give this impression. -- Stas Malyshev smalys...@gmail.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
