On Sat, 2014-02-01 at 20:30 +0100, Pierre Joye wrote:
> On Sat, Feb 1, 2014 at 8:11 PM, Johannes Schlüter
> <[email protected]> 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