Hello internals!
I have just opened voting on the RFC to add 4 new rounding modes to round()
function.
Voting will end November 30th, 00:00 GMT.
Link:
https://wiki.php.net/rfc/new_rounding_modes_to_round_function
I'm sorry for previous message, but completely missed the title of the
message.
Kind regards,
Jorg
Hello internals!
I have just opened voting on the RFC to add 4 new rounding modes toround()
function.Voting will end November 30th, 00:00 GMT.
Link:
https://wiki.php.net/rfc/new_rounding_modes_to_round_functionI'm sorry for previous message, but completely missed the title of the
message.Kind regards,
Jorg
I didn't pay attention to the discussion. Sorry.
I object to changing the intl code to add aliases. The intl extension
is a wrapper around ICU, and I don't think it's a wise choice to
modify it because you think "ROUND_TOWARD_ZERO" is better than
"ROUND_DOWN". I agree the name is better, but that's not really how
extension maintenance should work. I definitely don't think we should
then deprecate the ROUND_DOWN/ROUND_UP constants in ICU, given that
the extension itself hasn't deprecated them and is still maintained. I
am surprised nobody pointed this out before.
I don't have any objection to the rounding modes themselves.
Hello internals!
I have just opened voting on the RFC to add 4 new rounding modes to
round()
function.Voting will end November 30th, 00:00 GMT.
Link:
https://wiki.php.net/rfc/new_rounding_modes_to_round_functionI'm sorry for previous message, but completely missed the title of the
message.Kind regards,
JorgI didn't pay attention to the discussion. Sorry.
I object to changing the intl code to add aliases. The intl extension
is a wrapper around ICU, and I don't think it's a wise choice to
modify it because you think "ROUND_TOWARD_ZERO" is better than
"ROUND_DOWN". I agree the name is better, but that's not really how
extension maintenance should work. I definitely don't think we should
then deprecate the ROUND_DOWN/ROUND_UP constants in ICU, given that
the extension itself hasn't deprecated them and is still maintained. I
am surprised nobody pointed this out before.I don't have any objection to the rounding modes themselves.
Personally I am fine with adding aliases to ext/intl, it is not because the
extension is a wrapper that we can't enhance it to be somewhat consistent.
However, I do agree that deprecating the existing constants is a bad idea.
But the RFC vote, as far as I can understand, is not about deprecating it
in this release.
Best regards,
Gina P. Banyard
Thank you for your input Levi, this perspective wasn't mention before. I
agree with deprecation, that's why I removed this part from the RFC. I left
separate vote on creating aliases for the extension though, as from the
discussion this was not so certain and clear to everyone.
Kind regards,
Adam
Hello everyone,
The poll has been closed.
The RFC has been accepted with 19 votes yes and 0 votes no.
Creating aliases for Intl extension constants has been accepted with 10
votes yes and 6 votes no.
Thank you all for participating.
Kind regards,
Jorg
Hi,
Creating aliases for Intl extension constants has been accepted with 10
votes yes and 6 votes no.
This means that it is declined as you need 2/3 of votes to pass...
Cheers
Jakub
Hi,
Creating aliases for Intl extension constants has been accepted with 10
votes yes and 6 votes no.This means that it is declined as you need 2/3 of votes to pass...
This seems to be a secondary vote which only requires 50% of votes to be
accepted.
Best regards,
Gina P. Banyard
Hi,
Creating aliases for Intl extension constants has been accepted with 10
votes yes and 6 votes no.This means that it is declined as you need 2/3 of votes to pass...
This seems to be a secondary vote which only requires 50% of votes to be
accepted.
Ah I see now. It's a bit strange to have a secondary vote about sort of
unrelated thing in different extension but no one objected before or during
the vote so let's keep it accepted.
Cheers
Jakub
Hi,
Creating aliases for Intl extension constants has been accepted with 10
votes yes and 6 votes no.This means that it is declined as you need 2/3 of votes to pass...
This seems to be a secondary vote which only requires 50% of votes to be
accepted.Ah I see now. It's a bit strange to have a secondary vote about sort of
unrelated thing in different extension but no one objected before or during
the vote so let's keep it accepted.
I think so, however, I do agree that this was unclear, and we probably
should make sure future RFCs explicitly state if a vote is primary or not
and what the approval rate for the vote to be accepted should be.
Best regards,
Gina P. Banyard
I'm sorry for the confusion.
I followed the guide for the voting stating that the first voting is
primary, and rest are secondary, which don't require 2/3 votes on yes.
https://wiki.php.net/RFC/voting#voting
As this was my first RFC I was struggling a little bit, because the whole
description about RFCs are divided into several pages and in the template
there is not really an example for the primary and secondary voting. For
the new contributors some things are not entirely clear.
Maye we could improve the documentation of the process moving everything to
the Git? This could improve the transparency of the whole process and allow
for the clearer descriptions by the joint contribution?
Kind regards,
Jorg