On 6/13/2016 4:32 PM, Joe Watkins wrote: > You can count the number of people putting in the majority of this effort > on your fingers ... erecting a road block in front of them in the name of > unobtainable BC is harmful to the apparent goals of the project at this > time. >
The work of these people is highly appreciated and actively as well as publicly admired by the whole community. This is a fact. That being said, this is not about erecting a road block in front of them. This is about the same rights for all, something that is important in a community, especially in a community without any kind of leadership. Nobody is allowed to fix inconsistencies on an API level due to BC concerns. Nobody is allowed to renamed some constants (T_PYJAMA_NEKO anyone?) due to BC or nostalgic concerns. Yes, that stuff is mainly cosmetically. Yes, that stuff does not require the super magic skills that our engine gurus possess. Yes, you can count the people capable of doing any of this stuff on many hands. However, the rules should be the same for everyone in regards to BC. The rules should be clear. The rules should be understandable. Randomness and arbitrary decisions definitely do not help. I currently also think of changes like the php_url struct that would fix a bug but is an ABI break at the same time. This is being talked down in the PR over at GitHub because of that break and the author was requested to port it to PHP 7.1. I also remember that there was once a PR with random numbers that was meant to fix a bug but also stopped because of BC concerns (cannot find it, cannot give a reference but Sara was involved). What I am saying is. A BC promise cannot be arbitrary or it means BC hell for users and frustration for people who would like to contribute to internals. Simply because you one is not allowed to touch the code unless you count to the few gurus who are allowed to do whatever they want. (This is of course exaggerated now to make a point and biased.) On 6/13/2016 4:32 PM, Joe Watkins wrote: > I think our policy has always been to consider each proposal on a > case-by-case basis. That's all I have done, and all I am suggesting others > do. > > I know it's very strange to hear someone talking about "goals" ... > > We can waste a bunch of time trying to define them, voting on them, and so > on ... or, we can look at what is going on, and what has gone on, and come > to sensible conclusions. > Ultimately meaning that there is no BC promise whatsoever and everyone is at the mercy of the voters. This is especially striking me because one of the main arguments against many RFCs that want to deprecate something is that people will never upgrade because it makes upgrades hard for them (note, we are talking about deprecations here and BCs in much, much later versions). Introduction of random BCs is not? We definitely should make up goals, clear goals. Goals that are understandable by users. Goals that draw a vision of where we want to go. Improving the performance and engine could be on top of that, I am sure everybody will be in favor of it anyways. ;) -- Richard "Fleshgrinder" Fussenegger
signature.asc
Description: OpenPGP digital signature
