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

On Sat, 2014-02-01 at 20:30 +0100, Pierre Joye wrote: > 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. ... like core API 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. I understand your interpretation of the text, and going by the wording this might be correct, I still consider internal core APIs comparable. > >> 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. Even though it might be "proven" there are still issues, i.e. 21:53 < LawnGnome> cjones: /home/aharvey/trees/php-src/int64/ext/mysqli/mysqli_api.c:683:12: error: conflicting types for âmysqli_commit_or_rollback_libmysqlâ That one is most likely trivial (haven't done a libmysql build on that branch) to fix 22:05 <@johannes_> LawnGnome: should be a quite simple fix ... change mysqli_tx_cor_options_to_string and mysqli_commit_or_rollback_libmysql's signature touse the new type 22:06 < LawnGnome> johannes_: I'm sure you're right. I just disabled mysqli for now â I just want something I can phpize from so I can start seeing how good/bad/otherwise porting an extension to this is going to be for myself. but there likely are other small oversights. > >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. I comment on that further down in my previous message. > > 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. The issue is not reading it, but current type choices I can quote when woken at night and made drunk. Adoption takes time. > > 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've seen mostly messages appreciating the work. > > 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 :) Most messages I have read and most chatter I have seen rejects not the patch itself but the strong pushing it in with this timing. I think acceptance for master would be there. (unless people have too much time and find actual technical issues, of which I'm not aware) johannes