Re: [VOTE] 64 bit platform improvements for string length and integer

On Sat, Feb 1, 2014 at 8:11 PM, Johannes Schlüter <johannes@schlueters.de> wrote: > On Sat, 2014-02-01 at 19:35 +0100, Pierre Joye wrote: >> It is not, there is no change from user level but on windows and a 1-2 >> other platforms with long being 32 bit in 64bit. > > The current rule isn't precise, different interpretations are possible. > I lean to the side that a big change to the APIs is comparable to a > userland language change. I can see that this is read differently. This section of the RFC aims to protect from not well designed addition to the language, things affecting the long term maintenance and its core design. To make the internals implementation and APIs more 64bit aware, safer, cleaner and easier to deal with 64bit (compilation time check f.e.) is not something covered by this section. >> Also I find amazingly disturbing the amount of efforts you are putting >> to shut down this RFC, without a single comment in the last months or >> weeks, not even now to explain your vote. >> >> I do not mind a no, but what is happening here is disgusting, to say it nicely. > > Many contributors mentioned their concern about pushing in a patch > changing more than 20,000 lines of code now. Stability of this patch has been proven. Work has began for months. And if you look at the actual changes, they are much less problematic than a couple of small patches having disturbing releases for ages, or last minute addition of totally unstable extension, delaying release and early adoption for months. >I haven't seen much critic > on the implementation itself, simply the request for more time to > a) review it to make sure there are no accidental errors from conversion > and 99% of the implementation and options about it have been around for literally months. Sorry, this argument is totally invalid. > b) time to learn "the new way" before putting in a release, many have to > relearn thins hardwired in the brain for more than 10 years, such > adoption takes some time. I don't think anyone with little C experience needs more than 15mins to understand the changes, given the extensively verbose and migration guide. > Yes, we might have reviewed the branch sooner and learned the details > sooner but we are lazy and holding back in investing time in > "experimental" things. There is nothing experimental in this patch but a long awaited due cleanup and safe changes. We have been talking about that for ages. Our team finally took the beast by its horn and put a working, clean and safe patch. They tested it, very early, constantly, provided regular updates and requested feedback since months. I, personally, do not buy the laziness and lack of time argument. > I think a good way to proceed is to put it in master now and leave it > from 5.6. This forces everybody to look into it (and we will have lots > of opportunity to learn due to merging pain [which we have when putting > in 5.6, too]) and gives everybody enough time to adopt their brain and > prepare pecl (and internal) exts. That won't happen without another RFC and votes. We also drop all the options as we are most likely targeting 6 anyway. I won't be surprised to see the same arguments coming again btw :) Cheers, -- Pierre @pierrejoye | http://www.libgd.org