https://wiki.php.net/rfc/size_t_and_int64
There was two big questions regarding the compatibility. Those open
questions appeared in the discussions are reflected in the reworked RFC.
First question, the possibility to keep the old zend_parse_parameters()
specs 'l', 'L', 's', 'p' along with new 'i', 'I', 'S', 'P'. Keeping the
old zpp specs will for sure minimize the porting effort for the PECL
extensions, but might lead to confusion (like people might think ‘l’ still
expects ‘long’ and not ‘php_int_t’). Please use the yes/no Vote 3 to
decide whether the ‘l’, ‘L’, ‘s’, ‘p’ have to stay supported.
Second question, the macro renames for LONG<>INT, STRLEN<>STRSIZE, etc.
The reason for such renamings was to ensure source level incompatibility
on compile time. However this might have a negative effect on the porting
effort (despite the porting tools). Please use the yes/no Vote 2 to decide
whether the old macro names have to be kept.
The Vote 1 is the main vote for this patch. The both Votes 2 and 3 are
merely to decide about the semantical replacements choosen for the patch.
Should the Votes 2 and 3 result in reverting of that semantical changes,
the essential patch part about the 64 bit support will not be hurt.
Reverting to old macro names or zpp specs is only the naming issue.
Removal of the dead SAPIs is isolated in a separate RFC and can be
considered to another time.
Thanks for the constructive discussions on this RFC, support and testing.
The vote begins Monday, 27 January 2014, 21:30 CET and ends Monday, 03
February 2014, 21:30 CET.
https://wiki.php.net/rfc/size_t_and_int64
There was two big questions regarding the compatibility. Those open
questions appeared in the discussions are reflected in the reworked RFC.First question, the possibility to keep the old zend_parse_parameters()
specs 'l', 'L', 's', 'p' along with new 'i', 'I', 'S', 'P'. Keeping the
old zpp specs will for sure minimize the porting effort for the PECL
extensions, but might lead to confusion (like people might think 'l' still
expects 'long' and not 'php_int_t'). Please use the yes/no Vote 3 to
decide whether the 'l', 'L', 's', 'p' have to stay supported.Second question, the macro renames for LONG<>INT, STRLEN<>STRSIZE, etc.
The reason for such renamings was to ensure source level incompatibility
on compile time. However this might have a negative effect on the porting
effort (despite the porting tools). Please use the yes/no Vote 2 to decide
whether the old macro names have to be kept.The Vote 1 is the main vote for this patch. The both Votes 2 and 3 are
merely to decide about the semantical replacements choosen for the patch.
Should the Votes 2 and 3 result in reverting of that semantical changes,
the essential patch part about the 64 bit support will not be hurt.
Reverting to old macro names or zpp specs is only the naming issue.Removal of the dead SAPIs is isolated in a separate RFC and can be
considered to another time.Thanks for the constructive discussions on this RFC, support and testing.
The vote begins Monday, 27 January 2014, 21:30 CET and ends Monday, 03
February 2014, 21:30 CET.
Just to clarify my vote: I voted "No" on the RFC, but only because I think
the major extension source API break is better suited to PHP 6 than PHP
5.6. I fully support merging this into master, as the first change for PHP
Nikita
https://wiki.php.net/rfc/size_t_and_int64
There was two big questions regarding the compatibility. Those open
questions appeared in the discussions are reflected in the reworked RFC.First question, the possibility to keep the old zend_parse_parameters()
specs 'l', 'L', 's', 'p' along with new 'i', 'I', 'S', 'P'. Keeping the
old zpp specs will for sure minimize the porting effort for the PECL
extensions, but might lead to confusion (like people might think 'l' still
expects 'long' and not 'php_int_t'). Please use the yes/no Vote 3 to
decide whether the 'l', 'L', 's', 'p' have to stay supported.Second question, the macro renames for LONG<>INT, STRLEN<>STRSIZE, etc.
The reason for such renamings was to ensure source level incompatibility
on compile time. However this might have a negative effect on the porting
effort (despite the porting tools). Please use the yes/no Vote 2 to decide
whether the old macro names have to be kept.The Vote 1 is the main vote for this patch. The both Votes 2 and 3 are
merely to decide about the semantical replacements choosen for the patch.
Should the Votes 2 and 3 result in reverting of that semantical changes,
the essential patch part about the 64 bit support will not be hurt.
Reverting to old macro names or zpp specs is only the naming issue.Removal of the dead SAPIs is isolated in a separate RFC and can be
considered to another time.Thanks for the constructive discussions on this RFC, support and testing.
The vote begins Monday, 27 January 2014, 21:30 CET and ends Monday, 03
February 2014, 21:30 CET.Just to clarify my vote: I voted "No" on the RFC, but only because I think
the major extension source API break is better suited to PHP 6 than PHP
5.6. I fully support merging this into master, as the first change for PHP
Sad. As the work for pecl extensions is really not as large as you
think, fairly straight forward. The vote for php6 is not running now.
There is no option for PHP 6 as what can be done in php 6 internally
is much larger and would allow more breakage. On the other side, we
provide options to minimize the work for the extensions developers in
order of magnitude smaller than the changes we introduced in the past
for the OO APIs for example. Anyway, sad that you voted no for
something as important than true 64bit support.
Cheers,
Pierre
@pierrejoye | http://www.libgd.org
Just to clarify my vote: I voted "No" on the RFC, but only because I
think
the major extension source API break is better suited to PHP 6 than PHP
5.6. I fully support merging this into master, as the first change for
PHP
Sad. As the work for pecl extensions is really not as large as you
think, fairly straight forward. The vote for php6 is not running now.
There is no option for PHP 6 as what can be done in php 6 internally
is much larger and would allow more breakage. On the other side, we
provide options to minimize the work for the extensions developers in
order of magnitude smaller than the changes we introduced in the past
for the OO APIs for example. Anyway, sad that you voted no for
something as important than true 64bit support.
Maybe I'm indeed overestimating the impact. Could you please link to the
source-code for a PECL (or other third-party) extension that was ported to
be compatible with the new API, so people can see the actual impact this
makes? (Hopefully some ext that requires compat across multiple versions
like 5.3+ and has non-trivial amount of code and functions, like a few
dozen.) I couldn't find an example in RFC, but maybe I just missed it. Only
saw small snippets in there.
Nikita
Just to clarify my vote: I voted "No" on the RFC, but only because I
think
the major extension source API break is better suited to PHP 6 than PHP
5.6. I fully support merging this into master, as the first change for
PHP
Sad. As the work for pecl extensions is really not as large as you
think, fairly straight forward. The vote for php6 is not running now.
There is no option for PHP 6 as what can be done in php 6 internally
is much larger and would allow more breakage. On the other side, we
provide options to minimize the work for the extensions developers in
order of magnitude smaller than the changes we introduced in the past
for the OO APIs for example. Anyway, sad that you voted no for
something as important than true 64bit support.Maybe I'm indeed overestimating the impact. Could you please link to the
source-code for a PECL (or other third-party) extension that was ported to
be compatible with the new API, so people can see the actual impact this
makes? (Hopefully some ext that requires compat across multiple versions
like 5.3+ and has non-trivial amount of code and functions, like a few
dozen.) I couldn't find an example in RFC, but maybe I just missed it. Only
saw small snippets in there.Nikita
You could do a diff with OCI8 on str_size_and_int64 vs. master to see
one example.
I also have some additional unmerged patches related to a comment you
may see "/* XXX we assume that zend-zval len has 4 bytes */" since the
zval len is now a size_t and no longer 32 bits. I have more investigation
to do.
If the ZPP specs are not portable (vote #3), an additional 53 calls to
it will need #ifdef'ing so the code base is portable to older PHP
releases (because OCI8 is also released on PECL).
Chris
--
christopher.jones@oracle.com http://twitter.com/ghrd
Free PHP & Oracle book:
http://www.oracle.com/technetwork/topics/php/underground-php-oracle-manual-098250.html
Am 28.01.2014 21:24 schrieb "Nikita Popov" nikita.ppv@gmail.com:
https://wiki.php.net/rfc/size_t_and_int64
There was two big questions regarding the compatibility. Those open
questions appeared in the discussions are reflected in the reworked RFC.First question, the possibility to keep the old zend_parse_parameters()
specs 'l', 'L', 's', 'p' along with new 'i', 'I', 'S', 'P'. Keeping the
old zpp specs will for sure minimize the porting effort for the PECL
extensions, but might lead to confusion (like people might think 'l'
still
expects 'long' and not 'php_int_t'). Please use the yes/no Vote 3 to
decide whether the 'l', 'L', 's', 'p' have to stay supported.Second question, the macro renames for LONG<>INT, STRLEN<>STRSIZE, etc.
The reason for such renamings was to ensure source level incompatibility
on compile time. However this might have a negative effect on the
porting
effort (despite the porting tools). Please use the yes/no Vote 2 to
decide
whether the old macro names have to be kept.The Vote 1 is the main vote for this patch. The both Votes 2 and 3 are
merely to decide about the semantical replacements choosen for the
patch.
Should the Votes 2 and 3 result in reverting of that semantical changes,
the essential patch part about the 64 bit support will not be hurt.
Reverting to old macro names or zpp specs is only the naming issue.Removal of the dead SAPIs is isolated in a separate RFC and can be
considered to another time.Thanks for the constructive discussions on this RFC, support and
testing.
The vote begins Monday, 27 January 2014, 21:30 CET and ends Monday, 03
February 2014, 21:30 CET.Just to clarify my vote: I voted "No" on the RFC, but only because I think
the major extension source API break is better suited to PHP 6 than PHP
5.6. I fully support merging this into master, as the first change for PHP
Nikita
Sadly...
(From a long waiting Php user, who dont want to wait 2-3 years...)
Am 28.01.2014 21:24 schrieb "Nikita Popov" nikita.ppv@gmail.com:
https://wiki.php.net/rfc/size_t_and_int64
There was two big questions regarding the compatibility. Those open
questions appeared in the discussions are reflected in the reworked RFC.First question, the possibility to keep the old zend_parse_parameters()
specs 'l', 'L', 's', 'p' along with new 'i', 'I', 'S', 'P'. Keeping the
old zpp specs will for sure minimize the porting effort for the PECL
extensions, but might lead to confusion (like people might think 'l'
still
expects 'long' and not 'php_int_t'). Please use the yes/no Vote 3 to
decide whether the 'l', 'L', 's', 'p' have to stay supported.Second question, the macro renames for LONG<>INT, STRLEN<>STRSIZE, etc.
The reason for such renamings was to ensure source level incompatibility
on compile time. However this might have a negative effect on the
porting
effort (despite the porting tools). Please use the yes/no Vote 2 to
decide
whether the old macro names have to be kept.The Vote 1 is the main vote for this patch. The both Votes 2 and 3 are
merely to decide about the semantical replacements choosen for the
patch.
Should the Votes 2 and 3 result in reverting of that semantical changes,
the essential patch part about the 64 bit support will not be hurt.
Reverting to old macro names or zpp specs is only the naming issue.Removal of the dead SAPIs is isolated in a separate RFC and can be
considered to another time.Thanks for the constructive discussions on this RFC, support and
testing.
The vote begins Monday, 27 January 2014, 21:30 CET and ends Monday, 03
February 2014, 21:30 CET.Just to clarify my vote: I voted "No" on the RFC, but only because I think
the major extension source API break is better suited to PHP 6 than PHP
5.6. I fully support merging this into master, as the first change for PHP
Nikita
Sadly...
(From a long waiting Php user, who dont want to wait 2-3 years...)
The extension compatibility issue is not insignificant. Each voter
will have a different idea of how best to take PHP forward while
keeping the current user base happy.
Personnaly, I'd be glad to see the size_t_and_int64 vote halted until
PHP 6 is discussed a little more. This would give a clearer idea of
what BC breakages are likely in each release, and what the various
release timeframes are.
If the PHP 6 discussion doesn't happen or conclude quickly, then the
size_t_and_int64 vote can be restarted in time for any merge to 5.6.
Work on size_t_and_int64 and SAPI obsoletion etc should continue ready
for which ever branch it will be merged to.
I think I'm the only one (outside Anatol et al) actively looking at an
extension the new branch and have committed to it. I've some more
OCI8 patches pending, and more investigation to do. And then the
extension needs to be made compatible with older PHP releases. In
summary: migration is not a search and replace operation.
Chris
--
christopher.jones@oracle.com http://twitter.com/ghrd
Free PHP & Oracle book:
http://www.oracle.com/technetwork/topics/php/underground-php-oracle-manual-098250.html
Christopher Jones in php.internals (Tue, 28 Jan 2014 12:56:46 -0800):
I think I'm the only one (outside Anatol et al) actively looking at an
extension the new branch and have committed to it. I've some more
OCI8 patches pending, and more investigation to do. And then the
extension needs to be made compatible with older PHP releases. In
summary: migration is not a search and replace operation.
I ported the php-ffmpeg extension (not even PECL) to the new branch by
doing some simple search-and-replaces. I did this as a proof of concept
that the extension would survive he change. At the moment I have two
versions of the code, but it should be simple to merge the two versions
with some #ifdef's.
Jan
Hi Anatol,
As of renaming LONG to INT there is one small inconsistence in the RFC:
- ZEND_STRTOL/ZEND_STRTOUL should be ZEND_STRTOI/ZEND_STRTOUI
- SIZEOF_ZEND_INT should be ZEND_INT_SIZEOF to be consistent with
ZEND_INT_MAX/ZEND_INT_MIN/ZEND_UINT_MAX
And in my opinion if we go to rename LONG to INT with BC we should also
rename DOUBLE to FLOAT :)
Marc
https://wiki.php.net/rfc/size_t_and_int64
There was two big questions regarding the compatibility. Those open
questions appeared in the discussions are reflected in the reworked RFC.First question, the possibility to keep the old zend_parse_parameters()
specs 'l', 'L', 's', 'p' along with new 'i', 'I', 'S', 'P'. Keeping the
old zpp specs will for sure minimize the porting effort for the PECL
extensions, but might lead to confusion (like people might think ‘l’ still
expects ‘long’ and not ‘php_int_t’). Please use the yes/no Vote 3 to
decide whether the ‘l’, ‘L’, ‘s’, ‘p’ have to stay supported.Second question, the macro renames for LONG<>INT, STRLEN<>STRSIZE, etc.
The reason for such renamings was to ensure source level incompatibility
on compile time. However this might have a negative effect on the porting
effort (despite the porting tools). Please use the yes/no Vote 2 to decide
whether the old macro names have to be kept.The Vote 1 is the main vote for this patch. The both Votes 2 and 3 are
merely to decide about the semantical replacements choosen for the patch.
Should the Votes 2 and 3 result in reverting of that semantical changes,
the essential patch part about the 64 bit support will not be hurt.
Reverting to old macro names or zpp specs is only the naming issue.Removal of the dead SAPIs is isolated in a separate RFC and can be
considered to another time.Thanks for the constructive discussions on this RFC, support and testing.
The vote begins Monday, 27 January 2014, 21:30 CET and ends Monday, 03
February 2014, 21:30 CET.
Hi Marc,
thanks for the comments.
Hi Anatol,
As of renaming LONG to INT there is one small inconsistence in the RFC:
- ZEND_STRTOL/ZEND_STRTOUL should be ZEND_STRTOI/ZEND_STRTOUI
Sounds logic, as despite ZEND_STRTOL maps strtol(), zend_int_t for
instance also not necessarily 'int' literally. Just that the RFC is
already being voted ...
- SIZEOF_ZEND_INT should be ZEND_INT_SIZEOF to be consistent with
ZEND_INT_MAX/ZEND_INT_MIN/ZEND_UINT_MAX
This descends from things like SIZEOF_LONG and so on, so completely legit
for a C source.
And in my opinion if we go to rename LONG to INT with BC we should also
rename DOUBLE to FLOAT :)
Well, total renames was not the primary goal of this RFC. The renames
suggested are to reflect what's going on in the patch and to break
compilation with incompatible sources. Such topic asks for a new RFc :)
Regards
Anatol
https://wiki.php.net/rfc/size_t_and_int64
There was two big questions regarding the compatibility. Those open
questions appeared in the discussions are reflected in the reworked RFC.
Okay, so I've just looked at your attempt to port the MongoDB driver to
the "size_t" branch:
https://github.com/weltling/mongo-php-driver/compare/mongodb:master...master
And seriously, this one of the biggest mistakes I've seen in a while.
Changing APIs so much that basically half of your code needs an update,
or #ifdef hell. This is not acceptable, especially not for a PHP 5.X
branch — especially not so late in the game for 5.6!
And what is the gain? Absolutely nothing important. Who cares whether
you can have 2147483648 or 9223372036854775808 byte long strings? Or
whether some silly OS doesn't implement 64bit ints. Seriously, you are
forgetting how incredible much pain all extension authors have to go
through. This is not only ext/ or pecl/ or people hosting things in
GitHub, but also an enormous amount of internal extensions for
companies.
No, there is way too little benefit here to push that gigantuous amount
of work on developers, for zero to no gain. Atleast the introduction of
a unicode string type (à la "PHP 6") had a useful meaning.
I can't believe any sensible developer would vote to add this now into
5.6.
cheers,
Derick
--
http://derickrethans.nl | http://xdebug.org
Like Xdebug? Consider a donation: http://xdebug.org/donate.php
twitter: @derickr and @xdebug
Posted with an email client that doesn't mangle email: alpine
Hi!
Okay, so I've just looked at your attempt to port the MongoDB driver to
the "size_t" branch:
https://github.com/weltling/mongo-php-driver/compare/mongodb:master...masterAnd seriously, this one of the biggest mistakes I've seen in a while.
Changing APIs so much that basically half of your code needs an update,
or #ifdef hell. This is not acceptable, especially not for a PHP 5.X
branch — especially not so late in the game for 5.6!
Yeah, I looked at that patch and also at the diff between what
replace.php produces and what is the end result, and it kind of worries
me. Especially the part when you have to manually update all the types
and how easy it is to miss one. Not sure, if this is solved
automatically then I might be overreacting but right now it looks like
I, for example, have been underestimating the amount of code disruption
this is causing. I think refactoring PHP types and cleaning them up is a
good idea, but it also means I can't recommend 5.6 adoption to anybody
for years after the release, after we're sure extensions that were
disrupted are stable again. And we're not on stellar numbers with 5.5
adoption now, even given 5.4 to 5.5 supposed to be pretty much smooth
ride unless you mess with opcodes.
Again, I'm not against the idea of the patch or the implementation, but
looking at how much work it seems to take for ext author, I'd say it may
be a good start for PHP 6 branch.
--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
Hi!
Okay, so I've just looked at your attempt to port the MongoDB driver to
the "size_t" branch:
https://github.com/weltling/mongo-php-driver/compare/mongodb:master...masterAnd seriously, this one of the biggest mistakes I've seen in a while.
Changing APIs so much that basically half of your code needs an update,
or #ifdef hell. This is not acceptable, especially not for a PHP 5.X
branch — especially not so late in the game for 5.6!Yeah, I looked at that patch and also at the diff between what
replace.php produces and what is the end result, and it kind of worries
me.
There is a massive misunderstanding about the options provided in the votes.
If the option #2 and #3 are accepted, only, I repeat, only the
declarations of the variables used by zpp have to be changed, nothing
else, no #ifdef, etc.
Obviously codes relying on the size of the variable storing the length
of a char/buffer have to be changed or adapted as well, same goes for
64bit code on non linux platforms, or platforms having long not being
8 bytes on 64bit builds. The only other parts is the array index and
stat operation, but these are not related to the option #2 and #3 and
have to be done anyway already if one cares about LFS.
Especially the part when you have to manually update all the types
and how easy it is to miss one.
Not sure, if this is solved
automatically then I might be overreacting but right now it looks like
I, for example, have been underestimating the amount of code disruption
this is causing.
It can be automated for zpp, it is almost the case already and Anatol
is working on this part to fully automate zpp changes (with option #2
and #3).
I think refactoring PHP types and cleaning them up is a
good idea, but it also means I can't recommend 5.6 adoption to anybody
for years after the release, after we're sure extensions that were
disrupted are stable again. And we're not on stellar numbers with 5.5
adoption now, even given 5.4 to 5.5 supposed to be pretty much smooth
ride unless you mess with opcodes.Again, I'm not against the idea of the patch or the implementation, but
looking at how much work it seems to take for ext author, I'd say it may
be a good start for PHP 6 branch.
I will prepare a sample ext compiling using 5.3, 5.4, 5.5 and with the
int64 branch, it will be a better example than what we can see in
mongodb, which does not use option #2 and #3. It is basically bad as
many of us only focus on this constellation and totally ignore these
options which were added as a possible very good compromise.
Cheers,
Pierre
@pierrejoye | http://www.libgd.org
Hi!
There is a massive misunderstanding about the options provided in the votes.
If the option #2 and #3 are accepted, only, I repeat, only the
declarations of the variables used by zpp have to be changed, nothing
else, no #ifdef, etc.
I understand this. What is worrying me is that if you fail to do that
for some function, you end up using wrong variable type, and it would
lead to bugs that, from experience, are very hard to catch. If you
break the code explicitly, it plants a huge red flag saying "Here! You
need to fix this!". But if you just silently accept wrong types (and zpp
has no way of doing typechecks) then your best red flag would come in
the form of a user complaining "my PHP server crashes under the high
load with PHP 5.6".
I.e. if you do zpp("s", &char_ptr, &len) and zpp now expects len to be
size_t but you keep it declared as int, no tool will alert you and
you're putting 64-bit value into 32-bit stack slot.
It can be automated for zpp, it is almost the case already and Anatol
is working on this part to fully automate zpp changes (with option #2
and #3).
The bad part is not zpp. zpp is the easy part. The bad part is all vars
outside zpp and keeping them all in sync.
I will prepare a sample ext compiling using 5.3, 5.4, 5.5 and with the
int64 branch, it will be a better example than what we can see in
mongodb, which does not use option #2 and #3. It is basically bad as
many of us only focus on this constellation and totally ignore these
options which were added as a possible very good compromise.
I'm not ignoring that option. On the contrary, it is exactly that option
that you describe that I am worried about. And I am worried about it
exactly because since you don't have (meaning, forced by the compiler or
by zpp failure) to make the changes in all functions, it's all too easy
to miss one, and missing one is all to hard to figure out.
--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
Hi!
There is a massive misunderstanding about the options provided in the votes.
If the option #2 and #3 are accepted, only, I repeat, only the
declarations of the variables used by zpp have to be changed, nothing
else, no #ifdef, etc.I understand this. What is worrying me is that if you fail to do that
for some function, you end up using wrong variable type, and it would
lead to bugs that, from experience, are very hard to catch. If you
break the code explicitly, it plants a huge red flag saying "Here! You
need to fix this!". But if you just silently accept wrong types (and zpp
has no way of doing typechecks) then your best red flag would come in
the form of a user complaining "my PHP server crashes under the high
load with PHP 5.6".
I.e. if you do zpp("s", &char_ptr, &len) and zpp now expects len to be
size_t but you keep it declared as int, no tool will alert you and
you're putting 64-bit value into 32-bit stack slot.It can be automated for zpp, it is almost the case already and Anatol
is working on this part to fully automate zpp changes (with option #2
and #3).The bad part is not zpp. zpp is the easy part.
Very easy even, the replace.php will take care of this part.
The bad part is all vars
outside zpp and keeping them all in sync.I will prepare a sample ext compiling using 5.3, 5.4, 5.5 and with the
int64 branch, it will be a better example than what we can see in
mongodb, which does not use option #2 and #3. It is basically bad as
many of us only focus on this constellation and totally ignore these
options which were added as a possible very good compromise.I'm not ignoring that option. On the contrary, it is exactly that option
that you describe that I am worried about. And I am worried about it
exactly because since you don't have (meaning, forced by the compiler or
by zpp failure) to make the changes in all functions, it's all too easy
to miss one, and missing one is all to hard to figure out.
That's where the compiler warnings/errors come to the game. Except for
the situations where one does explicit bad casting, which should be
avoided in the 1st place, if possible.
That being said, I have been advocated warning free php-src for years
now. I think if we ever start php6 then we should really change our
policy and get clean codes. Any warning can produce undefined
behaviors or changing behaviors. Using gcc and VC as base should put
us on the safe side. Both gcc and vc latest versions have new options
to actually get rid of many of the issues you are describing easily.
Cheers,
Pierre
@pierrejoye | http://www.libgd.org
Hi!
That's where the compiler warnings/errors come to the game. Except for
the situations where one does explicit bad casting, which should be
avoided in the 1st place, if possible.
Could you explain how compiler can handle zpp("s", &char_ptr, &len) with
len being wrong type? If you show me the way for the compiler to warn on
this, you've gone a long way towards convincing me - but so far I've
seen no way to do it. And this is for me one of the major points where
it could break so many things. Any suggestions?
That being said, I have been advocated warning free php-src for years
now. I think if we ever start php6 then we should really change our
The problem is nobody wants to work on it. Nobody even cares too much
for keeping unit tests green, which should be way above no warnings in
the priorities ladder. We definitely should do it, but how many people
would sign up for "no warnings" effort as opposed to "new syntax, yay!"
effort? That's like washing dishes instead of playing Minecraft. Don't
get me wrong - I'm all for it and will try to dedicate some of my
copious free time to it (thanks for the reminder, btw). But can we
really pull it off? I hope I'm being too pessimistic here.
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
Hi all,
On Fri, Jan 31, 2014 at 9:42 AM, Stas Malyshev smalyshev@sugarcrm.comwrote:
Okay, so I've just looked at your attempt to port the MongoDB driver to
the "size_t" branch:https://github.com/weltling/mongo-php-driver/compare/mongodb:master...master
And seriously, this one of the biggest mistakes I've seen in a while.
Changing APIs so much that basically half of your code needs an update,
or #ifdef hell. This is not acceptable, especially not for a PHP 5.X
branch — especially not so late in the game for 5.6!Yeah, I looked at that patch and also at the diff between what
replace.php produces and what is the end result, and it kind of worries
me. Especially the part when you have to manually update all the types
and how easy it is to miss one. Not sure, if this is solved
automatically then I might be overreacting but right now it looks like
I, for example, have been underestimating the amount of code disruption
this is causing. I think refactoring PHP types and cleaning them up is a
good idea, but it also means I can't recommend 5.6 adoption to anybody
for years after the release, after we're sure extensions that were
disrupted are stable again. And we're not on stellar numbers with 5.5
adoption now, even given 5.4 to 5.5 supposed to be pretty much smooth
ride unless you mess with opcodes.Again, I'm not against the idea of the patch or the implementation, but
looking at how much work it seems to take for ext author, I'd say it may
be a good start for PHP 6 branch.
Once code is updated, then it's a matter of including compatibility header
for older PHP, is't it? However, it's requires many line of changes.
Personally,
I don't mind it at all, though.
Although, I would like to see it soon. It may be better to introduce it from
6 and start 6 branch now. Even if we choose this path, it would be better
provide new type and macro definition to PHP 5.x for 3rd party modules.
Regards,
--
Yasuo Ohgaki
yohgaki@ohgaki.net
Although, I would like to see it soon. It may be better to introduce it from
6 and start 6 branch now.
I see you've already voted for it, so I'm not sure if you have changed your
mind, or are on the fence about it. The vote ends on Monday, so hopefully
you will have decided one way or another by then.
Chris
--
christopher.jones@oracle.com http://twitter.com/ghrd
Free PHP & Oracle book:
http://www.oracle.com/technetwork/topics/php/underground-php-oracle-manual-098250.html
Hi Christopher,
On Sat, Feb 1, 2014 at 6:43 AM, Christopher Jones <
christopher.jones@oracle.com> wrote:
Although, I would like to see it soon. It may be better to introduce it
from
6 and start 6 branch now.I see you've already voted for it, so I'm not sure if you have changed your
mind, or are on the fence about it. The vote ends on Monday, so hopefully
you will have decided one way or another by then.
I would like to have it ASAP personally :)
Just an idea for better migration path for newer PHP in general.
Regards,
--
Yasuo Ohgaki
yohgaki@ohgaki.net
On Fri, 2014-01-31 at 00:56 +0100, Derick Rethans wrote:
https://wiki.php.net/rfc/size_t_and_int64
There was two big questions regarding the compatibility. Those open
questions appeared in the discussions are reflected in the reworked RFC.Okay, so I've just looked at your attempt to port the MongoDB driver to
the "size_t" branch:
https://github.com/weltling/mongo-php-driver/compare/mongodb:master...master
I never said that were the full worky port. I did that in 2 hours as it
was asked to be done on some extension, and you know that. It can be got
ready in several days. So I've chosen this as an example on what the
effort could be. Should I have taken an easy one with 5 minutes effort,
like scream? But you prefer to interpret some complex case as an average
one.
And seriously, this one of the biggest mistakes I've seen in a while.
Changing APIs so much that basically half of your code needs an update,
or #ifdef hell. This is not acceptable, especially not for a PHP 5.X
branch — especially not so late in the game for 5.6!And what is the gain? Absolutely nothing important. Who cares whether
you can have 2147483648 or 9223372036854775808 byte long strings? Or
whether some silly OS doesn't implement 64bit ints. Seriously, you are
forgetting how incredible much pain all extension authors have to go
through. This is not only ext/ or pecl/ or people hosting things in
GitHub, but also an enormous amount of internal extensions for
companies.
So with next major you mean you would abandon the 5.x support in your exts, as
it's too much? Reverting the semantic changes is a wimp. The effort you're talking
about is a one time action, or can you point to another RFC of such globality?
Without effort even a cat isn't getting born :)
The compatibility path is being developed and improved, and it will be of
course nothing without your as well as everyone's else participation. But
you're right, who cares?
No, there is way too little benefit here to push that gigantuous amount
of work on developers, for zero to no gain. Atleast the introduction of
a unicode string type (à la "PHP 6") had a useful meaning.I can't believe any sensible developer would vote to add this now into
5.6.
It was started to have it consistent overall. The next step after it
were the performance improvement on 64 bit. Then one could think about
the dependency libs improvement. To whose costs goes this delay?
Technically, as well as socially. Just because it's not getting done. It
is a technical debt which is growing every day. Would I see that done
berofe I'm retired, or would my grandkids at least? Suppressing things
doesn't improve anything.
Regards
Anatol
On Fri, 2014-01-31 at 00:56 +0100, Derick Rethans wrote:
https://wiki.php.net/rfc/size_t_and_int64
There was two big questions regarding the compatibility. Those open
questions appeared in the discussions are reflected in the reworked RFC.Okay, so I've just looked at your attempt to port the MongoDB driver to
the "size_t" branch:
https://github.com/weltling/mongo-php-driver/compare/mongodb:master...masterI never said that were the full worky port. I did that in 2 hours as it
was asked to be done on some extension, and you know that. It can be got
ready in several days.
"Several days" for one extension. Imagine that you maintain a dozen. Are
you really expecting that people will like it to have to spend a month
porting all their extensions for such a marginal benefit? And that for a
minor release?
So I've chosen this as an example on what the effort could be. Should
I have taken an easy one with 5 minutes effort, like scream? But you
prefer to interpret some complex case as an average one.
Seriously, the MongoDB extension isn't that complicated. There are a lot
of methods, but no different from any other database extension.
And seriously, this one of the biggest mistakes I've seen in a while.
Changing APIs so much that basically half of your code needs an update,
or #ifdef hell. This is not acceptable, especially not for a PHP 5.X
branch — especially not so late in the game for 5.6!And what is the gain? Absolutely nothing important. Who cares whether
you can have 2147483648 or 9223372036854775808 byte long strings? Or
whether some silly OS doesn't implement 64bit ints. Seriously, you are
forgetting how incredible much pain all extension authors have to go
through. This is not only ext/ or pecl/ or people hosting things in
GitHub, but also an enormous amount of internal extensions for
companies.So with next major you mean you would abandon the 5.x support in your
exts, as it's too much?
No, absolutely not. Right now, we have to support 5.2 to 5.6—I think I
even support 5.1 for Xdebug. But with this change, the 5.6 compatible
code is drastically different from the 5.2-5.5 ones.
No, there is way too little benefit here to push that gigantuous
amount of work on developers, for zero to no gain. Atleast the
introduction of a unicode string type (à la "PHP 6") had a useful
meaning.I can't believe any sensible developer would vote to add this now
into 5.6.It was started to have it consistent overall. The next step after it
were the performance improvement on 64 bit. Then one could think about
the dependency libs improvement. To whose costs goes this delay?
Technically, as well as socially. Just because it's not getting done.
It is a technical debt which is growing every day.
Uhm, the current situation works just fine. I wouldn't call this
technical debt. I am also not saying that this branch is not a good
thing—but so would be "consistent function naming" or "case sensitive
function/method names"—and we're not never going to get these either.
cheers,
Derick
--
http://derickrethans.nl | http://xdebug.org
Like Xdebug? Consider a donation: http://xdebug.org/donate.php
twitter: @derickr and @xdebug
Posted with an email client that doesn't mangle email: alpine
2014-01-31 Derick Rethans derick@php.net:
https://wiki.php.net/rfc/size_t_and_int64
There was two big questions regarding the compatibility. Those open
questions appeared in the discussions are reflected in the reworked
RFC.Okay, so I've just looked at your attempt to port the MongoDB driver to
the "size_t" branch:https://github.com/weltling/mongo-php-driver/compare/mongodb:master...master
I never said that were the full worky port. I did that in 2 hours as it
was asked to be done on some extension, and you know that. It can be got
ready in several days."Several days" for one extension. Imagine that you maintain a dozen. Are
you really expecting that people will like it to have to spend a month
porting all their extensions for such a marginal benefit? And that for a
minor release?
I ask you, does it really matter if you have to do it for 5.6 or 6.0? You
have to do it anyway sooner or later. For once, I feel that if I had a
dozen extensions to maintain, I would welcome the ability to spread the
workload between adopting 64 bit support in 5.6 and adopting whatever big
changes will come with 6.0 (and as that is a major versions - there
probably will be _A LOT) of stuff changing).
Sometimes fanatically sticking to the rules of development is not the best
course of action - you have to make exceptions in some cases and try to
adjust the workflow so that you don't end up forcing people to do too much
work at once. Otherwise you end up with slow adoption.
So I've chosen this as an example on what the effort could be. Should
I have taken an easy one with 5 minutes effort, like scream? But you
prefer to interpret some complex case as an average one.Seriously, the MongoDB extension isn't that complicated. There are a lot
of methods, but no different from any other database extension.
There are always some extensions with a much bigger work needed to be done
than the rest. Database extensions are one of the biggest challenges to
convert.
And seriously, this one of the biggest mistakes I've seen in a while.
Changing APIs so much that basically half of your code needs an update,
or #ifdef hell. This is not acceptable, especially not for a PHP 5.X
branch — especially not so late in the game for 5.6!And what is the gain? Absolutely nothing important. Who cares whether
you can have 2147483648 or 9223372036854775808 byte long strings? Or
whether some silly OS doesn't implement 64bit ints. Seriously, you are
forgetting how incredible much pain all extension authors have to go
through. This is not only ext/ or pecl/ or people hosting things in
GitHub, but also an enormous amount of internal extensions for
companies.So with next major you mean you would abandon the 5.x support in your
exts, as it's too much?No, absolutely not. Right now, we have to support 5.2 to 5.6—I think I
even support 5.1 for Xdebug. But with this change, the 5.6 compatible
code is drastically different from the 5.2-5.5 ones.
5.3 is in the EOL phase and is not maintained at this point. It's EOL ends
in June. So with 5.6 all you have to maintain is 5.4 to 5.6 . Remember - no
more than 3 branches at one time are supported.
No, there is way too little benefit here to push that gigantuous
amount of work on developers, for zero to no gain. Atleast the
introduction of a unicode string type (à la "PHP 6") had a useful
meaning.I can't believe any sensible developer would vote to add this now
into 5.6.It was started to have it consistent overall. The next step after it
were the performance improvement on 64 bit. Then one could think about
the dependency libs improvement. To whose costs goes this delay?
Technically, as well as socially. Just because it's not getting done.
It is a technical debt which is growing every day.Uhm, the current situation works just fine. I wouldn't call this
technical debt. I am also not saying that this branch is not a good
thing—but so would be "consistent function naming" or "case sensitive
function/method names"—and we're not never going to get these either.
Sorry, it's not a technical dept? As a userland developer, I had my moments
cursing the PHP developers in general for not properly working PHP in 64
bit environment. True, maybe I'm that not so often case of the PHP
developer working with stuff that needs those 64 bit integer (my project
does not work under 64 bit windows properly) to do my calculations because
32 bit integer is too small.
P.S. I want to mention the general trend in the software development of
"fuck 64 bits, it can run in 32 bit mode anyway". And we get what we get -
almost a decade of 64 bit processor availability and half the software
still doesn't not support it properly. This is just a remark.
2014-01-31 Derick Rethans derick@php.net:
So with next major you mean you would abandon the 5.x support in your
exts, as it's too much?No, absolutely not. Right now, we have to support 5.2 to 5.6—I think I
even support 5.1 for Xdebug. But with this change, the 5.6 compatible
code is drastically different from the 5.2-5.5 ones.5.3 is in the EOL phase and is not maintained at this point. It's EOL
ends in June. So with 5.6 all you have to maintain is 5.4 to 5.6 .
Remember - no more than 3 branches at one time are supported.
My commercial customers as well as my current employer disagrees.
Whatever "php.net" decides not to support anymore has no impact on the
commercial world. There is a lot more custom extensions out there than
you probably expect.
Uhm, the current situation works just fine. I wouldn't call this
technical debt. I am also not saying that this branch is not a good
thing—but so would be "consistent function naming" or "case
sensitive function/method names"—and we're not never going to get
these either.Sorry, it's not a technical dept? As a userland developer, I had my
moments cursing the PHP developers in general for not properly working
PHP in 64 bit environment.
PHP works just fine a proper 64-bit environment.
cheers,
Derick
--
http://derickrethans.nl | http://xdebug.org
Like Xdebug? Consider a donation: http://xdebug.org/donate.php
twitter: @derickr and @xdebug
Posted with an email client that doesn't mangle email: alpine
2014-01-31 Derick Rethans derick@php.net:
https://wiki.php.net/rfc/size_t_and_int64
There was two big questions regarding the compatibility. Those open
questions appeared in the discussions are reflected in the reworked
RFC.Okay, so I've just looked at your attempt to port the MongoDB driver to
the "size_t" branch:https://github.com/weltling/mongo-php-driver/compare/mongodb:master...master
I never said that were the full worky port. I did that in 2 hours as it
was asked to be done on some extension, and you know that. It can be got
ready in several days."Several days" for one extension. Imagine that you maintain a dozen. Are
you really expecting that people will like it to have to spend a month
porting all their extensions for such a marginal benefit? And that for a
minor release?I ask you, does it really matter if you have to do it for 5.6 or 6.0? You
have to do it anyway sooner or later. For once, I feel that if I had a
dozen extensions to maintain, I would welcome the ability to spread the
workload between adopting 64 bit support in 5.6 and adopting whatever big
changes will come with 6.0 (and as that is a major versions - there
probably will be _A LOT) of stuff changing).
Sometimes fanatically sticking to the rules of development is not the best
course of action - you have to make exceptions in some cases and try to
adjust the workflow so that you don't end up forcing people to do too much
work at once. Otherwise you end up with slow adoption.
breaking API big time twice is better than breaking it once?
So I've chosen this as an example on what the effort could be. Should
I have taken an easy one with 5 minutes effort, like scream? But you
prefer to interpret some complex case as an average one.Seriously, the MongoDB extension isn't that complicated. There are a lot
of methods, but no different from any other database extension.There are always some extensions with a much bigger work needed to be done
than the rest. Database extensions are one of the biggest challenges to
convert.And seriously, this one of the biggest mistakes I've seen in a while.
Changing APIs so much that basically half of your code needs an update,
or #ifdef hell. This is not acceptable, especially not for a PHP 5.X
branch — especially not so late in the game for 5.6!And what is the gain? Absolutely nothing important. Who cares whether
you can have 2147483648 or 9223372036854775808 byte long strings? Or
whether some silly OS doesn't implement 64bit ints. Seriously, you are
forgetting how incredible much pain all extension authors have to go
through. This is not only ext/ or pecl/ or people hosting things in
GitHub, but also an enormous amount of internal extensions for
companies.So with next major you mean you would abandon the 5.x support in your
exts, as it's too much?No, absolutely not. Right now, we have to support 5.2 to 5.6—I think I
even support 5.1 for Xdebug. But with this change, the 5.6 compatible
code is drastically different from the 5.2-5.5 ones.5.3 is in the EOL phase and is not maintained at this point. It's EOL ends
in June. So with 5.6 all you have to maintain is 5.4 to 5.6 . Remember - no
more than 3 branches at one time are supported.
heh, and you think that after this date nobody will use 5.3 and ext devs
will just say - "uprgade or don't use my functionality". Let's see.
Mongo tries to get more customers, which means that 5.3 will be
important for them, even after EOL, because 5.3 has already worked in
the environment of the customer and the single change is just Mongo added.
No, there is way too little benefit here to push that gigantuous
amount of work on developers, for zero to no gain. Atleast the
introduction of a unicode string type (à la "PHP 6") had a useful
meaning.I can't believe any sensible developer would vote to add this now
into 5.6.It was started to have it consistent overall. The next step after it
were the performance improvement on 64 bit. Then one could think about
the dependency libs improvement. To whose costs goes this delay?
Technically, as well as socially. Just because it's not getting done.
It is a technical debt which is growing every day.Uhm, the current situation works just fine. I wouldn't call this
technical debt. I am also not saying that this branch is not a good
thing—but so would be "consistent function naming" or "case sensitive
function/method names"—and we're not never going to get these either.Sorry, it's not a technical dept? As a userland developer, I had my moments
cursing the PHP developers in general for not properly working PHP in 64
bit environment. True, maybe I'm that not so often case of the PHP
developer working with stuff that needs those 64 bit integer (my project
does not work under 64 bit windows properly) to do my calculations because
32 bit integer is too small.
maybe because Windows is broken in that regard and the fix that comes is
about fixing Windows but invoicing all OSes.
P.S. I want to mention the general trend in the software development of
"fuck 64 bits, it can run in 32 bit mode anyway". And we get what we get -
almost a decade of 64 bit processor availability and half the software
still doesn't not support it properly. This is just a remark.
Because only a few applications need real 64 bit. Databases are one example.
Andrey
And seriously, this one of the biggest mistakes I've seen in a while.
Changing APIs so much that basically half of your code needs an update,
or #ifdef hell. This is not acceptable, especially not for a PHP 5.X
branch — especially not so late in the game for 5.6!
Late?
And what is the gain? Absolutely nothing important. Who cares whether
you can have 2147483648 or 9223372036854775808 byte long strings? Or
whether some silly OS doesn't implement 64bit ints.
Please re read the discussions about this RFC and the RFC, it is not
only about that. If there is something still unclear, please raise
your questions.
Seriously, you are
forgetting how incredible much pain all extension authors have to go
through. This is not only ext/ or pecl/ or people hosting things in
GitHub, but also an enormous amount of internal extensions for
companies.
I do not think it has been forgotten. And many of the voters maintain
(many) extensions as well, so do I.
Cheers,
Pierre
And seriously, this one of the biggest mistakes I've seen in a while.
Changing APIs so much that basically half of your code needs an update,
or #ifdef hell. This is not acceptable, especially not for a PHP 5.X
branch — especially not so late in the game for 5.6!Late?
Yes, in case you didn't know, 5.6 already has a release:
http://www.php.net/archive/2014.php#id2014-01-23-1
cheers,
Derick
--
http://derickrethans.nl | http://xdebug.org
Like Xdebug? Consider a donation: http://xdebug.org/donate.php
twitter: @derickr and @xdebug
Posted with an email client that doesn't mangle email: alpine
And seriously, this one of the biggest mistakes I've seen in a while.
Changing APIs so much that basically half of your code needs an update,
or #ifdef hell. This is not acceptable, especially not for a PHP 5.X
branch — especially not so late in the game for 5.6!Late?
Yes, in case you didn't know, 5.6 already has a release:
http://www.php.net/archive/2014.php#id2014-01-23-1
Check when the RFC was proposed, when it was initially created, how
many mails have been sent to the list to get feedback about how things
are done, etc. etc.
So excuse me, but I am totally not going any "late" argument,
especially as almost everyone voting no did not say a single word in
months. In the other hands, other arguments about the amount of
changes are very valid and that's why option #2 and #3 have been
added, see my last reply to Stas for more details.
--
Pierre
@pierrejoye | http://www.libgd.org
https://wiki.php.net/rfc/size_t_and_int64
There was two big questions regarding the compatibility. Those open
questions appeared in the discussions are reflected in the reworked RFC.First question, the possibility to keep the old zend_parse_parameters()
specs 'l', 'L', 's', 'p' along with new 'i', 'I', 'S', 'P'. Keeping the
old zpp specs will for sure minimize the porting effort for the PECL
extensions, but might lead to confusion (like people might think ‘l’ still
expects ‘long’ and not ‘php_int_t’). Please use the yes/no Vote 3 to
decide whether the ‘l’, ‘L’, ‘s’, ‘p’ have to stay supported.Second question, the macro renames for LONG<>INT, STRLEN<>STRSIZE, etc.
The reason for such renamings was to ensure source level incompatibility
on compile time. However this might have a negative effect on the porting
effort (despite the porting tools). Please use the yes/no Vote 2 to decide
whether the old macro names have to be kept.The Vote 1 is the main vote for this patch. The both Votes 2 and 3 are
merely to decide about the semantical replacements choosen for the patch.
Should the Votes 2 and 3 result in reverting of that semantical changes,
the essential patch part about the 64 bit support will not be hurt.
Reverting to old macro names or zpp specs is only the naming issue.Removal of the dead SAPIs is isolated in a separate RFC and can be
considered to another time.Thanks for the constructive discussions on this RFC, support and testing.
The vote begins Monday, 27 January 2014, 21:30 CET and ends Monday, 03
February 2014, 21:30 CET.
Hi Anatol,
A quick question: am I right to assume that because this vote has
widespread impact on PHP it needs 2/3 majority per https://wiki.php.net/rfc/voting ?
It's not totally clear that the change is covered by any of the examples
in the voting RFC, but I see the 64 bit project as affecting the language
as a whole (for better or worse!)
Chris
PS I've updated the RFC template to remind authors to state
the acceptance criteria in the RFC.
--
christopher.jones@oracle.com http://twitter.com/ghrd
Free PHP & Oracle book:
http://www.oracle.com/technetwork/topics/php/underground-php-oracle-manual-098250.html
Hi Chris,
https://wiki.php.net/rfc/size_t_and_int64
There was two big questions regarding the compatibility. Those open
questions appeared in the discussions are reflected in the reworked RFC.First question, the possibility to keep the old zend_parse_parameters()
specs 'l', 'L', 's', 'p' along with new 'i', 'I', 'S', 'P'. Keeping
the old zpp specs will for sure minimize the porting effort for the PECL
extensions, but might lead to confusion (like people might think ‘l’
still expects ‘long’ and not ‘php_int_t’). Please use the yes/no Vote 3
to decide whether the ‘l’, ‘L’, ‘s’, ‘p’ have to stay supported.Second question, the macro renames for LONG<>INT, STRLEN<>STRSIZE, etc.
The reason for such renamings was to ensure source level
incompatibility on compile time. However this might have a negative
effect on the porting effort (despite the porting tools). Please use the
yes/no Vote 2 to decide whether the old macro names have to be kept.The Vote 1 is the main vote for this patch. The both Votes 2 and 3 are
merely to decide about the semantical replacements choosen for the
patch. Should the Votes 2 and 3 result in reverting of that semantical
changes, the essential patch part about the 64 bit support will not be
hurt. Reverting to old macro names or zpp specs is only the naming
issue.Removal of the dead SAPIs is isolated in a separate RFC and can be
considered to another time.Thanks for the constructive discussions on this RFC, support and
testing. The vote begins Monday, 27 January 2014, 21:30 CET and ends
Monday, 03
February 2014, 21:30 CET.Hi Anatol,
A quick question: am I right to assume that because this vote has
widespread impact on PHP it needs 2/3 majority per
https://wiki.php.net/rfc/voting ?It's not totally clear that the change is covered by any of the examples
in the voting RFC, but I see the 64 bit project as affecting the language
as a whole (for better or worse!)
catching up on this now as this was delayed by the mail issues.
I'm not a native speaker, however what i read here
[QUOTE]
We also need to ensure, as much as possible, that the decision isn't based
on some arbitrary circumstances (such as a temporary marginal majority for
a certain school of thought). For these reasons, a feature affecting the
language itself (new syntax for example) will be considered as 'accepted'
if it wins a 2/3 of the votes. Other RFCs require 50% + 1 votes to get
'accepted'.
[/QUOTE]
sounds for 50%+1, as it affects not the language itself (no syntax
changes, etc.) but its implementation. Even in such an unusual case :)
Regards
Anatol
On Fri, Jan 31, 2014 at 9:26 PM, Anatol Belski anatol.php@belski.netwrote:
Hi Anatol,
A quick question: am I right to assume that because this vote has
widespread impact on PHP it needs 2/3 majority per
https://wiki.php.net/rfc/voting ?It's not totally clear that the change is covered by any of the examples
in the voting RFC, but I see the 64 bit project as affecting the language
as a whole (for better or worse!)catching up on this now as this was delayed by the mail issues.
I'm not a native speaker, however what i read here
[QUOTE]
We also need to ensure, as much as possible, that the decision isn't based
on some arbitrary circumstances (such as a temporary marginal majority for
a certain school of thought). For these reasons, a feature affecting the
language itself (new syntax for example) will be considered as 'accepted'
if it wins a 2/3 of the votes. Other RFCs require 50% + 1 votes to get
'accepted'.
[/QUOTE]sounds for 50%+1, as it affects not the language itself (no syntax
changes, etc.) but its implementation. Even in such an unusual case :)Regards
Anatol
Changing the integer type used by the language is most certainly a language
change. "New syntax" is only given as an example of what constitutes a
language change.
Nikita
Hi Chris,
https://wiki.php.net/rfc/size_t_and_int64
There was two big questions regarding the compatibility. Those open
questions appeared in the discussions are reflected in the reworked RFC.First question, the possibility to keep the old zend_parse_parameters()
specs 'l', 'L', 's', 'p' along with new 'i', 'I', 'S', 'P'. Keeping
the old zpp specs will for sure minimize the porting effort for the PECL
extensions, but might lead to confusion (like people might think ‘l’
still expects ‘long’ and not ‘php_int_t’). Please use the yes/no Vote 3
to decide whether the ‘l’, ‘L’, ‘s’, ‘p’ have to stay supported.Second question, the macro renames for LONG<>INT, STRLEN<>STRSIZE, etc.
The reason for such renamings was to ensure source level
incompatibility on compile time. However this might have a negative
effect on the porting effort (despite the porting tools). Please use the
yes/no Vote 2 to decide whether the old macro names have to be kept.The Vote 1 is the main vote for this patch. The both Votes 2 and 3 are
merely to decide about the semantical replacements choosen for the
patch. Should the Votes 2 and 3 result in reverting of that semantical
changes, the essential patch part about the 64 bit support will not be
hurt. Reverting to old macro names or zpp specs is only the naming
issue.Removal of the dead SAPIs is isolated in a separate RFC and can be
considered to another time.Thanks for the constructive discussions on this RFC, support and
testing. The vote begins Monday, 27 January 2014, 21:30 CET and ends
Monday, 03
February 2014, 21:30 CET.Hi Anatol,
A quick question: am I right to assume that because this vote has
widespread impact on PHP it needs 2/3 majority per
https://wiki.php.net/rfc/voting ?It's not totally clear that the change is covered by any of the examples
in the voting RFC, but I see the 64 bit project as affecting the language
as a whole (for better or worse!)catching up on this now as this was delayed by the mail issues.
I'm not a native speaker, however what i read here
[QUOTE]
We also need to ensure, as much as possible, that the decision isn't based
on some arbitrary circumstances (such as a temporary marginal majority for
a certain school of thought). For these reasons, a feature affecting the
language itself (new syntax for example) will be considered as 'accepted'
if it wins a 2/3 of the votes. Other RFCs require 50% + 1 votes to get
'accepted'.
[/QUOTE]sounds for 50%+1, as it affects not the language itself (no syntax
changes, etc.) but its implementation. Even in such an unusual case :)Regards
Anatol
The voting RFC's use of "for example" indicates that syntax changes are
just one part of "feature[s] affecting the language".
I agree that the 64-bit RFC doesn't affect syntax. However it does
materially affect the language, so I believe it requires a 2/3
majority.
Chris
PS It's a pain to be micro-analyzing like this, but that's what the
PHP community got when it decided to formalize the feature adoption
process.
--
christopher.jones@oracle.com http://twitter.com/ghrd
Free PHP & Oracle book:
http://www.oracle.com/technetwork/topics/php/underground-php-oracle-manual-098250.html
PS It's a pain to be micro-analyzing like this, but that's what the
PHP community got when it decided to formalize the feature adoption
process.
Part of the problem here is that that process is worded very poorly.
There is way too much space for people's interpretation; and that will
mean that in the future, more of this rushing is likely going to happen.
cheers,
Derick
I agree that the 64-bit RFC doesn't affect syntax. However it does
materially
affect the language, so I believe it requires a 2/3 majority.
I'd consider it a language-changing RFC. The 2/3 majority is related to
material changes in the language, and as you said, syntax changes are just
one (although the most common) such example. The 50%+1 is really for
extension-level changes - mostly new functions/extensions, moving stuff
to/from PECL, etc.
Zeev
I agree that the 64-bit RFC doesn't affect syntax. However it does
materially
affect the language, so I believe it requires a 2/3 majority.I'd consider it a language-changing RFC. The 2/3 majority is related to
material changes in the language, and as you said, syntax changes are just
one (although the most common) such example. The 50%+1 is really for
extension-level changes - mostly new functions/extensions, moving stuff
to/from PECL, etc.
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.
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.
Cheers,
Pierre
@pierrejoye | http://www.libgd.org
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.
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. 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
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.
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.
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.
johannes
On Sat, Feb 1, 2014 at 8:11 PM, Johannes Schlüter
johannes@schlueters.de 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
On Sat, Feb 1, 2014 at 8:11 PM, Johannes Schlüter
johannes@schlueters.de 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
and99% 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
I agree that the 64-bit RFC doesn't affect syntax. However it does
materially
affect the language, so I believe it requires a 2/3 majority.I'd consider it a language-changing RFC. The 2/3 majority is related to
material changes in the language, and as you said, syntax changes are just
one (although the most common) such example. The 50%+1 is really for
extension-level changes - mostly new functions/extensions, moving stuff
to/from PECL, etc.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.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.
Cheers,
I believe Zeev was giving an opinion on the question I asked, no more or less,
in reference to the ambiguous voting RFC.
Chris
--
christopher.jones@oracle.com http://twitter.com/ghrd
Free PHP & Oracle book:
http://www.oracle.com/technetwork/topics/php/underground-php-oracle-manual-098250.html
I agree that the 64-bit RFC doesn't affect syntax. However it does
materially
affect the language, so I believe it requires a 2/3 majority.I'd consider it a language-changing RFC. The 2/3 majority is related to
material changes in the language, and as you said, syntax changes are just
one (although the most common) such example. The 50%+1 is really for
extension-level changes - mostly new functions/extensions, moving stuff
to/from PECL, etc.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.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.
What is "disgusting" is trying to push through an RFC that doesn't have
broad consensus (for 5.6), while on the other hand effects way more
people that some people on this list want to make out.
Derick
--
http://derickrethans.nl | http://xdebug.org
Like Xdebug? Consider a donation: http://xdebug.org/donate.php
twitter: @derickr and @xdebug
Posted with an email client that doesn't mangle email: alpine
What is "disgusting" is trying to push through an RFC that doesn't have
broad consensus (for 5.6), while on the other hand effects way more
people that some people on this list want to make out.
We did not push anything harder or softer than any other. There were
many discussions in the past (where you were totally absent btw) and
there were discussions two weeks before the votes. I do not think I
need to redo the arguing about each other arguments, we all know where
we stand.
--
Pierre
@pierrejoye | http://www.libgd.org
Am 01.02.2014 19:35, schrieb Pierre Joye:
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.
AFAIK, there's no duty for explaining ones opinion prior to voting.
Ulf
I agree that the 64-bit RFC doesn't affect syntax. However it does
materially
affect the language, so I believe it requires a 2/3 majority.I'd consider it a language-changing RFC. The 2/3 majority is related to
material changes in the language, and as you said, syntax changes are just
one (although the most common) such example. The 50%+1 is really for
extension-level changes - mostly new functions/extensions, moving stuff
to/from PECL, etc.
Maybe a good difference might be
* Patches touching main/, TSRM/ or Zend/ require 2/3rd
* Patches touching only individually SAPIs or exts require 50%
johannes
-----Original Message-----
From: Johannes Schlüter [mailto:johannes@schlueters.de]
Sent: Saturday, February 01, 2014 8:38 PM
To: Zeev Suraski
Cc: Christopher Jones; Anatol Belski; PHP Developers Mailing List
Subject: RE: [PHP-DEV] [VOTE] 64 bit platform improvements for string
length and integerI agree that the 64-bit RFC doesn't affect syntax. However it does
materially affect the language, so I believe it requires a 2/3
majority.I'd consider it a language-changing RFC. The 2/3 majority is related
to material changes in the language, and as you said, syntax changes
are just one (although the most common) such example. The 50%+1 is
really for extension-level changes - mostly new functions/extensions,
moving stuff to/from PECL, etc.Maybe a good difference might be
* Patches touching main/, TSRM/ or Zend/ require 2/3rd * Patches touching only individually SAPIs or exts require 50%
Probably a clean good way to differentiate, sounds good to me.
Zeev
Hi!
Maybe a good difference might be
* Patches touching main/, TSRM/ or Zend/ require 2/3rd * Patches touching only individually SAPIs or exts require 50%
I'm not a big fan of over-formalizing things and thus setting up
ourselves for the trap of rules being used against the rules' original
purpose. I think nobody can deny this is a big change in the core. For
big changes we need big consensus. For small changes - even if the
change happens to be in a file stored in main/ - simple majority is enough.
I don't know if it is workable anymore or not, but so far PHP has always
been governed by consensus, and trying to find a way of governing itself
that is acceptable to the people composing the group. I think voting
50%+1 on such a big thing is not good, especially given that everybody
from 50%-1 that was against it and continues to work with the core will
have to support the consequences of it for years to come. I think that
was the main driver between distinction on 50%+1 and 2/3 - if the change
is going to influence PHP in a way that nearly everybody working with
PHP has to deal with - it requires broader consensus. If it's localized
and can be handled in isolation from the other things - majority is ok,
if you hate it, you can work in another corner :)
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
Maybe a good difference might be
* Patches touching main/, TSRM/ or Zend/ require 2/3rd * Patches touching only individually SAPIs or exts require 50%I'm not a big fan of over-formalizing things and thus setting up
ourselves for the trap of rules being used against the rules' original
purpose.
Heh. That happens already now too... So I'd rather be more descriptive.
The release process and voting RFCs are so incredible vague.
cheers,
Derick
http://derickrethans.nl | http://xdebug.org
Like Xdebug? Consider a donation: http://xdebug.org/donate.php
twitter: @derickr and @xdebug
Posted with an email client that doesn't mangle email: alpine
Heh. That happens already now too...
Not really, except in extreme cases where one tries to block a thing
using one way or another. However I do not think either we need 2/3 to
change something in the Engine, core or extension but what is actually
exposed to the users, which we have to maintain for BC reasons for
years. On the other hand, internals are more flexible and can be
changed without impacting existing applications.
So I'd rather be more descriptive.
The release process and voting RFCs are so incredible vague.
The only vague part is about major releases (like 6) as it is merely
impossible to define a time frame for them. Everything else is rather
clear and has worked quite well for the numerous submitted RFCs.
That being said, we can clarify the major release process and try to
put some time frames in them. But I am not in favor of over formalized
the other parts and try to keep relying on common senses, even if the
latter has some hard time lately.
Cheers,
Pierre
@pierrejoye | http://www.libgd.org
Heh. That happens already now too...
Not really, except in extreme cases where one tries to block a thing
using one way or another. However I do not think either we need 2/3 to
change something in the Engine, core or extension but what is actually
exposed to the users, which we have to maintain for BC reasons for
years. On the other hand, internals are more flexible and can be
changed without impacting existing applications.So I'd rather be more descriptive.
The release process and voting RFCs are so incredible vague.The only vague part is about major releases (like 6) as it is merely
impossible to define a time frame for them. Everything else is rather
clear and has worked quite well for the numerous submitted RFCs.That being said, we can clarify the major release process and try to
put some time frames in them. But I am not in favor of over formalized
the other parts and try to keep relying on common senses, even if the
latter has some hard time lately.
Ok to clarify it, sure.
I'm all +1 to branch 6 after 5.6 is released (say during 2014) , we
have some talented contributors, some ideas, some motivation feeling
and we are at PHP5 + 10 years.
I think we'll need at least 2 years developement, if not 3.
All this depends on what we want to do with PHP6, and this must be
community debatted, open.
I hope people will understand issues of PHP6, and won't start drama
again and again :-p
Julien
A quick question: am I right to assume that because this vote has
widespread impact on PHP it needs 2/3 majority per
https://wiki.php.net/rfc/voting ?It's not totally clear that the change is covered by any of the
examples in the voting RFC, but I see the 64 bit project as
affecting the language as a whole (for better or worse!)catching up on this now as this was delayed by the mail issues.
I'm not a native speaker, however what i read here
[QUOTE]
We also need to ensure, as much as possible, that the decision isn't based
on some arbitrary circumstances (such as a temporary marginal majority for
a certain school of thought). For these reasons, a feature affecting the
language itself (new syntax for example) will be considered as 'accepted'
if it wins a 2/3 of the votes. Other RFCs require 50% + 1 votes to get
'accepted'.
[/QUOTE]sounds for 50%+1, as it affects not the language itself (no syntax
changes, etc.) but its implementation. Even in such an unusual case :)
I am not sure, but syntax is only given as an example there. And I would
argue that this is definitely a language change. Having a stable and
easy extension API has always been one of PHP's greatest strenghts,
especially in the early days where PHP was a very thin glue layer.
Actually, I would argue that PHP is still such a layer, even though
people write massive libraries and frameworks.
cheers,
Derick
--
http://derickrethans.nl | http://xdebug.org
Like Xdebug? Consider a donation: http://xdebug.org/donate.php
twitter: @derickr and @xdebug
Posted with an email client that doesn't mangle email: alpine
It is my understanding that part of the reason for the release workflow
RFC was that if patches miss the mark they don't have to wait for long
till the next release comes.
In this case here we have 5.6.0alpaha1 out. Adding a major API change
touching each and every file can't be added to 5.6 anymore.
Also the release process RFC says
x.y.z to x.y+1.z
[...]
ABI and API can be broken (internals), src compatibility
should
be kept if possible, while breakages are allowed
This rule contains many things that "can" and "should" and thus is open
to interprettation. In my interpretation this rule is meant to allow
small changes, affecting only few extensions and where it would be
stupid to defer the.
I think adding this patch to 5.x therefore would be quite some bending
of that rule and that combined with the fact that it is late makes me
believe that proposing this for 5.6 is illegal.
johannes
Am 31.01.2014 13:36, schrieb Johannes Schlüter:
I think adding this patch to 5.x therefore would be quite some bending
of that rule and that combined with the fact that it is late makes me
believe that proposing this for 5.6 is illegal.
Are you saying the RFC is 'illegal' ? If the subject proposed is not
allowed, it would make litte sense collecting votes.
Ulf
Am 31.01.2014 13:36, schrieb Johannes Schlüter:
I think adding this patch to 5.x therefore would be quite some bending
of that rule and that combined with the fact that it is late makes me
believe that proposing this for 5.6 is illegal.Are you saying the RFC is 'illegal' ? If the subject proposed is not
allowed, it would make litte sense collecting votes.
I think the RM has to reject this from 5.6 independently from the voting
result as he is bound by the release process RFC.
johannes
On Fri, Jan 31, 2014 at 1:55 PM, Johannes Schlüter
johannes@schlueters.de wrote:
Am 31.01.2014 13:36, schrieb Johannes Schlüter:
I think adding this patch to 5.x therefore would be quite some bending
of that rule and that combined with the fact that it is late makes me
believe that proposing this for 5.6 is illegal.Are you saying the RFC is 'illegal' ? If the subject proposed is not
allowed, it would make litte sense collecting votes.I think the RM has to reject this from 5.6 independently from the voting
result as he is bound by the release process RFC.
I think you should stop to try to block things using all possible tools :)
FYI: https://wiki.php.net/todo/php56
--
Pierre
@pierrejoye | http://www.libgd.org
On Fri, Jan 31, 2014 at 1:55 PM, Johannes Schlüter
johannes@schlueters.de wrote:Am 31.01.2014 13:36, schrieb Johannes Schlüter:
I think adding this patch to 5.x therefore would be quite some bending
of that rule and that combined with the fact that it is late makes me
believe that proposing this for 5.6 is illegal.Are you saying the RFC is 'illegal' ? If the subject proposed is not
allowed, it would make litte sense collecting votes.I think the RM has to reject this from 5.6 independently from the voting
result as he is bound by the release process RFC.I think you should stop to try to block things using all possible tools :)
I'm just using your rules.
And well, I like the idea that this change gives us - long term - higher
quality code which is a good thing. But as this benefit is long time I
see little need to push it through. The more predictable yearly release
cycle gives us a way without taking too much risk.
The fact that it is on a todo is nice. It still missed alpha1, either
the alpha would have had to be delayed or it has to wait for the next
version.
On the point whether this should be in 5.7 (if that exists) or 6
whatever I don't care too much. For 5.6 it is too late.
johannes
Am 31.01.2014 13:55, schrieb Johannes Schlüter:
Am 31.01.2014 13:36, schrieb Johannes Schlüter:
I think adding this patch to 5.x therefore would be quite some bending
of that rule and that combined with the fact that it is late makes me
believe that proposing this for 5.6 is illegal.Are you saying the RFC is 'illegal' ? If the subject proposed is not
allowed, it would make litte sense collecting votes.I think the RM has to reject this from 5.6 independently from the voting
result as he is bound by the release process RFC.
Thanks for explaining. The three takeaway point for me are:
- you are serious about following the rules
- a radical minded person may refuse to vote in the first place
Ulf
Am 31.01.2014 13:55, schrieb Johannes Schlüter:
Am 31.01.2014 13:36, schrieb Johannes Schlüter:
I think adding this patch to 5.x therefore would be quite some bending
of that rule and that combined with the fact that it is late makes me
believe that proposing this for 5.6 is illegal.Are you saying the RFC is 'illegal' ? If the subject proposed is not
allowed, it would make litte sense collecting votes.I think the RM has to reject this from 5.6 independently from the voting
result as he is bound by the release process RFC.Thanks for explaining. The three takeaway point for me are:
- you are serious about following the rules
Seriously. which rule define this RFC or any other RFC breaking ABI as
not allowed? There is none. And this discussions takes a ridiculous
course, can we be serious now please? :)
- a radical minded person may refuse to vote in the first place
I would say extremist, but yes ;)
--
Pierre
@pierrejoye | http://www.libgd.org
Am 31.01.2014 14:11, schrieb Pierre Joye:
Seriously. which rule define this RFC or any other RFC breaking ABI as
not allowed? There is none. And this discussions takes a ridiculous
course, can we be serious now please? :)
There is nothing more serious than trying to understand someone else
arguments.
Ulf
-----Original Message-----
From: Johannes Schlüter [mailto:johannes@schlueters.de]
Sent: Friday, January 31, 2014 2:55 PM
To: Ulf Wendel
Cc: internals@lists.php.net
Subject: Re: [PHP-DEV] [VOTE] 64 bit platform improvements for string
length and integerAm 31.01.2014 13:36, schrieb Johannes Schlüter:
I think adding this patch to 5.x therefore would be quite some
bending of that rule and that combined with the fact that it is late
makes me believe that proposing this for 5.6 is illegal.Are you saying the RFC is 'illegal' ? If the subject proposed is not
allowed, it would make litte sense collecting votes.I think the RM has to reject this from 5.6 independently from the voting
result as he is bound by the release process RFC.
All,
I have to add something here.
Many of the people voting on that RFC have never ever contributed as much as
a single line of code into the PHP source tree, and a couple have literally
contributed low-single-digit patches.
Incidentally, as far as I could tell, all of them[*] voted in favor of the
proposed changes (i.e. source compatibility breakage).
Even though having non-code-contributors makes a lot of sense for decisions
regarding the language's features and we built in support for it in the
voting RFC, in my opinion, it makes no sense at all for people who have no
stake at the development of the language's source code to weigh in on how
that code is written. Personally I didn't expect we'd be voting on things
like that (implementation style) back when I was involved in the voting RFC,
but perhaps it's time to amend it a bit.
If you fall in that category, please do the right thing and delete your
vote.
Zeev
All,
I have to add something here.
Many of the people voting on that RFC have never ever contributed as much as
a single line of code into the PHP source tree, and a couple have literally
contributed low-single-digit patches.
Incidentally, as far as I could tell, all of them[*] voted in favor of the
proposed changes (i.e. source compatibility breakage).Even though having non-code-contributors makes a lot of sense for decisions
regarding the language's features and we built in support for it in the
voting RFC, in my opinion, it makes no sense at all for people who have no
stake at the development of the language's source code to weigh in on how
that code is written. Personally I didn't expect we'd be voting on things
like that (implementation style) back when I was involved in the voting RFC,
but perhaps it's time to amend it a bit.If you fall in that category, please do the right thing and delete your
vote.Zeev
You might need to contact such people individually, since they
conceivably will miss your email in the morass of postings.
I would be interested in your opinion on the majority required:
http://marc.info/?l=php-internals&m=139112879612711&w=2
Chris
--
christopher.jones@oracle.com http://twitter.com/ghrd
Free PHP & Oracle book:
http://www.oracle.com/technetwork/topics/php/underground-php-oracle-manual-098250.html
On Fri, Jan 31, 2014 at 10:51 PM, Christopher Jones
christopher.jones@oracle.com wrote:
All,
I have to add something here.
Many of the people voting on that RFC have never ever contributed as much
as
a single line of code into the PHP source tree, and a couple have
literally
contributed low-single-digit patches.
Incidentally, as far as I could tell, all of them[*] voted in favor of the
proposed changes (i.e. source compatibility breakage).Even though having non-code-contributors makes a lot of sense for
decisions
regarding the language's features and we built in support for it in the
voting RFC, in my opinion, it makes no sense at all for people who have no
stake at the development of the language's source code to weigh in on how
that code is written. Personally I didn't expect we'd be voting on things
like that (implementation style) back when I was involved in the voting
RFC,
but perhaps it's time to amend it a bit.If you fall in that category, please do the right thing and delete your
vote.
I think the right thing to do is to actually not posting such
respect-less and misinformed requests. It is wrong and rude in so many
ways. Please double check who voted and what they did. Also I would
also not going down the road of active contributors either, not even
remotely.
Cheers,
Pierre
@pierrejoye | http://www.libgd.org
-----Original Message-----
From: Johannes Schlüter [mailto:johannes@schlueters.de]
Sent: Friday, January 31, 2014 2:55 PM
To: Ulf Wendel
Cc: internals@lists.php.net
Subject: Re: [PHP-DEV] [VOTE] 64 bit platform improvements for string
length and integerAm 31.01.2014 13:36, schrieb Johannes Schlüter:
I think adding this patch to 5.x therefore would be quite some
bending of that rule and that combined with the fact that it is late
makes me believe that proposing this for 5.6 is illegal.Are you saying the RFC is 'illegal' ? If the subject proposed is not
allowed, it would make litte sense collecting votes.I think the RM has to reject this from 5.6 independently from the voting
result as he is bound by the release process RFC.All,
I have to add something here.
Many of the people voting on that RFC have never ever contributed as much
as
a single line of code into the PHP source tree, and a couple have literally
contributed low-single-digit patches.
Incidentally, as far as I could tell, all of them[*] voted in favor of the
proposed changes (i.e. source compatibility breakage).Even though having non-code-contributors makes a lot of sense for decisions
regarding the language's features and we built in support for it in the
voting RFC, in my opinion, it makes no sense at all for people who have no
stake at the development of the language's source code to weigh in on how
that code is written. Personally I didn't expect we'd be voting on things
like that (implementation style) back when I was involved in the voting
RFC,
but perhaps it's time to amend it a bit.If you fall in that category, please do the right thing and delete your
vote.
Hi Zeev,
I think that this vote also makes sense for maintainers of PECL extensions
as they will need to do lots of work.
I am aware what the patch does and how much work I will need to do in my
extensions. I actually did the openssl part of the 64bit patch just to see
what changes will be required for my crypto ext which also is an openssl
wrapper. And yes it will require lots of changes. Probably the most time
consuming part of the porting (that wasn't mentioned here) is looking to
the different versions of the libs and testing how it affects the
extension. There are sometimes types changes between different versions of
libs which can result in nasty bugs. For example the size_t change could
even result to some security issues if it's not handled properly.
The reason why I voted YES is that I don't see any difference if the patch
is merged now or in the future. The work will need to be done anyway. It
will just require more time that will need to be spent on maintaining the
64bit branch if the patch is merged later.
Thanks
Regards
Jakub
I think that this vote also makes sense for maintainers of PECL extensions
as they will need to do lots of work.I am aware what the patch does and how much work I will need to do in my
extensions. I actually did the openssl part of the 64bit patch just to see
what changes will be required for my crypto ext which also is an openssl
wrapper. And yes it will require lots of changes. Probably the most time
consuming part of the porting (that wasn't mentioned here) is looking to
the different versions of the libs and testing how it affects the
extension. There are sometimes types changes between different versions of
libs which can result in nasty bugs. For example the size_t change could
even result to some security issues if it's not handled properly.The reason why I voted YES is that I don't see any difference if the patch
is merged now or in the future. The work will need to be done anyway. It
will just require more time that will need to be spent on maintaining the
64bit branch if the patch is merged later.
Also see Anatol latest post to internals, the sample extension shows
the difference between a 5.3/4/5 code and one supporting 5.3/4/5 and
with the int64 patch with the option #2 and #3. The changes are really
straightforward and far less intrusive than without these options.
--
Pierre
@pierrejoye | http://www.libgd.org
Pierre Joye wrote:
Also see Anatol latest post to internals, the sample extension shows
the difference between a 5.3/4/5 code and one supporting 5.3/4/5 and
with the int64 patch with the option #2 and #3. The changes are really
straightforward and far less intrusive than without these options.
I see that the vote currently has swung from yes to no for including in 5.6 but
actually there is no option to include it even in PHP6? The improvement is
required, needs proper planning because of the impact on many third parties, and
should be planned now on the basis of a new PHP6.
That said, I still see no reply to my enquiry as to how this will affect user
land usage between 32 and 64 bit builds. To this end, vote 3 would seem to
directly impact how we format displays and is one of the areas that I am
concerned that there will be a difference between the two builds? What I would
like to see in the RFC is some proper documentation on the differences between
the two so that we can plan on how this is handled when moving from PHP5 to PHP6
( even if you call it PHP5.6 ;) ) ...
The current disagreement is not about including it, but simply how it is
included. I would prefer that you now leave PHP5 alone and simply get on with a
parallel development of PHP6 ... which currently the vote would seem to support?
People how need the 64bit improvements can run PHP6 early ... I ran PHP5 for 6
months before it was actually released simply to avoid having to worry about 4
back then. A little bit of fun as things changed, but it keeps the effects of
missing extensions nicely ring fenced?
--
Lester Caine - G8HFL
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk
Pierre Joye wrote:
Also see Anatol latest post to internals, the sample extension shows
the difference between a 5.3/4/5 code and one supporting 5.3/4/5 and
with the int64 patch with the option #2 and #3. The changes are really
straightforward and far less intrusive than without these options.I see that the vote currently has swung from yes to no for including in
5.6 but actually there is no option to include it even in PHP6? The
improvement is required, needs proper planning because of the impact on
many third parties, and should be planned now on the basis of a new PHP6.
Nobody said that if rejected this can't be considered for PHP6.
On the contrary, many of the no voters explained that they would have voted
yes if the target version would have been 6.0.
--
Ferenc Kovács
@Tyr43l - http://tyrael.hu
Ferenc Kovacs wrote:
Also see Anatol latest post to internals, the sample extension shows the difference between a 5.3/4/5 code and one supporting 5.3/4/5 and with the int64 patch with the option #2 and #3. The changes are really straightforward and far less intrusive than without these options. I see that the vote currently has swung from yes to no for including in 5.6 but actually there is no option to include it even in PHP6? The improvement is required, needs proper planning because of the impact on many third parties, and should be planned now on the basis of a new PHP6.Nobody said that if rejected this can't be considered for PHP6.
On the contrary, many of the no voters explained that they would have voted yes
if the target version would have been 6.0.
Sorry Ferenc ... that was just a little dig at the people commenting on the
minutia of how a vote should be carried out ;) The other questions were the
important bit ...
--
Lester Caine - G8HFL
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk
Hello,
-----Original Message-----
From: Ferenc Kovacs [mailto:tyra3l@gmail.com]I see that the vote currently has swung from yes to no for including
in
5.6 but actually there is no option to include it even in PHP6? The
improvement is required, needs proper planning because of the impact
on many third parties, and should be planned now on the basis of a new
PHP6.Nobody said that if rejected this can't be considered for PHP6.
On the contrary, many of the no voters explained that they would have
voted yes if the target version would have been 6.0.
This is not directed at you guys in particular, but this is just the latest thread to mention PHP6 so I'll say it here. I know at least my team is frustrated every time "why not PHP6?" is mentioned in this thread.
There is no PHP 6. If there was this RFC would have had two simple options; merge for PHP 6.0, merge for both 5.6 & 6.0. The justification for the latter option being that 5.6+ would provide a more reasonable upgrade path for 6. It may not be meant this way, but suggesting we merge this into PHP6 simply sounds disrespectful. There's no point in targeting some ethereal release, that's just a way of kicking this down the road so it can be ignored for a little longer. Without a plan forward to a release, even merging to Master is just another place for this to languish.
And yes, I know there has been some (hopefully) serious discussion on PHP6 recently, but that happens every year. Maybe it will happen this time? IMHO, if PHP 5 has slipped happily into middle age and cannot fathom such change anymore, then perhaps this community should create a roadmap to a new branch where more progressive development can be realized.
Thanks,
Steve
On Sat, Feb 1, 2014 at 8:19 PM, Stephen Zarkos <Stephen.Zarkos@microsoft.com
wrote:
Hello,
-----Original Message-----
From: Ferenc Kovacs [mailto:tyra3l@gmail.com]I see that the vote currently has swung from yes to no for including
in
5.6 but actually there is no option to include it even in PHP6? The
improvement is required, needs proper planning because of the impact
on many third parties, and should be planned now on the basis of a new
PHP6.Nobody said that if rejected this can't be considered for PHP6.
On the contrary, many of the no voters explained that they would have
voted yes if the target version would have been 6.0.This is not directed at you guys in particular, but this is just the
latest thread to mention PHP6 so I'll say it here. I know at least my team
is frustrated every time "why not PHP6?" is mentioned in this thread.There is no PHP 6. If there was this RFC would have had two simple
options; merge for PHP 6.0, merge for both 5.6 & 6.0. The justification
for the latter option being that 5.6+ would provide a more reasonable
upgrade path for 6. It may not be meant this way, but suggesting we merge
this into PHP6 simply sounds disrespectful. There's no point in targeting
some ethereal release, that's just a way of kicking this down the road so
it can be ignored for a little longer. Without a plan forward to a
release, even merging to Master is just another place for this to languish.And yes, I know there has been some (hopefully) serious discussion on PHP6
recently, but that happens every year. Maybe it will happen this time?
IMHO, if PHP 5 has slipped happily into middle age and cannot fathom such
change anymore, then perhaps this community should create a roadmap to a
new branch where more progressive development can be realized.Thanks,
Steve
I'm glad that you agree with me on the urgent need of a major release on
the roadmap, otherwise changes which would be best to ship in a major
version will be either discarded, or worse forced into a minor version:
http://marc.info/?l=php-internals&m=138494774314060&w=4
Still, it feels a bit disrespectful to reply to my mails as if I would be
the one who tries to sabotage this change through putting it into "some
ethereal release".
ps: I still don't think that it is a good thing to start to turning this
into a "now or never" kind of decision.
--
Ferenc Kovács
@Tyr43l - http://tyrael.hu
From: Ferenc Kovacs [mailto:tyra3l@gmail.com]
Hello,
-----Original Message-----
From: Ferenc Kovacs [mailto:tyra3l@gmail.com]I see that the vote currently has swung from yes to no for including
in
5.6 but actually there is no option to include it even in PHP6? The
improvement is required, needs proper planning because of the impact
on many third parties, and should be planned now on the basis of a new
PHP6.Nobody said that if rejected this can't be considered for PHP6.
On the contrary, many of the no voters explained that they would have
voted yes if the target version would have been 6.0.
This is not directed at you guys in particular, but this is just the latest thread to
mention PHP6 so I'll say it here. I know at least my team is frustrated every
time "why not PHP6?" is mentioned in this thread.There is no PHP 6. If there was this RFC would have had two simple options;
merge for PHP 6.0, merge for both 5.6 & > 6.0. The justification for the latter
option being that 5.6+ would provide a more reasonable upgrade path for 6.
It may not be meant this way, but suggesting we merge this into PHP6 simply
sounds disrespectful. There's no point in targeting some ethereal release,
that's just a way of kicking this down the road so it can be ignored for a little
longer. Without a plan forward to a release, even merging to Master is just
another place for this to languish.And yes, I know there has been some (hopefully) serious discussion on
PHP6 recently, but that happens every year. Maybe it will happen this
time? IMHO, if PHP 5 has slipped happily into middle age and cannot fathom
such change anymore, then perhaps this community should create a roadmap
to a new branch where more progressive development can be realized.Thanks,
SteveI'm glad that you agree with me on the urgent need of a major release on the
roadmap, otherwise changes which would be best to ship in a major version
will be either discarded, or worse forced into a minor version:http://marc.info/
?l=php-internals&m=138494774314060&w=4
Still, it feels a bit disrespectful to reply to my mails as if I would be the one who
tries to sabotage this change through putting it into "some ethereal release".
It wasn't directed to you specifically. That's why I said above that it wasn't directed to you. This was just the latest mention of the "why not php6" argument on this so it was the best place to respond. Apologies if it came off wrong.
ps: I still don't think that it is a good thing to start to turning this into a "now or
never" kind of decision.
The point was that it must be targeted to a real release. Without a release to aim for I cannot imagine how to justify such a big effort (or continuing effort). But I also don't think anyone really thinks that it's now or never. Perhaps it seems that way since (like any release cycle) everyone's excited and eager to get their feature in.
Thanks,
Steve
Hi!
There is no PHP 6. If there was this RFC would have had two simple
options; merge for PHP 6.0, merge for both 5.6 & 6.0. The
justification for the latter option being that 5.6+ would provide a
more reasonable upgrade path for 6. It may not be meant this way,
but suggesting we merge this into PHP6 simply sounds disrespectful.
There's no point in targeting some ethereal release, that's just a
way of kicking this down the road so it can be ignored for a little
longer. Without a plan forward to a release, even merging to Master
is just another place for this to languish.
There is no PHP 6, that is true. But there will be, unless we consider
this patch a good way to close the project and go home. I hope nobody
thinks that way. Thus, there will be PHP 6. And not as some pie in the
sky, but as a next version, which needs to happen. Yes, we do not have a
release plan or roadmap for it yet. But I think we realize the need for
it and we can work on it. If this does not happen, we can also realize
it did not happen in time for bringing this patch in for 5.7 - with
the knowledge that PHP 6 is not realistic anymore, knowledge that we do
not have now.
I do not see how it is disrespectful to suggest a high-risk change
should be happening in a major version which is supposed to cause major
breakage. You may agree or disagree but this has nothing to do with
respect. I can't speak for others but I can speak for myself in saying
that these concerns are not just kicking the can down the road in hope
that eventually this patch dies off. This is a real and genuine concern
about the disruption caused and I actually do want this to happen - just
not in a way that would make 5.6 the release to never use for a huge set
of customers.
And yes, I know there has been some (hopefully) serious discussion
on PHP6 recently, but that happens every year. Maybe it will happen
this time? IMHO, if PHP 5 has slipped happily into middle age and
cannot fathom such change anymore, then perhaps this community
should create a roadmap to a new branch where more progressive
development can be realized.
This branch is exactly what we're talking about when we're talking of
PHP 6.
We must realize that we have dual responsibility here, with both
progress and existing base support being at least equally important,
arguably the latter even more important, even if less glamorous.
Thus, we have to maintain the balance. And if we have big changes that
are necessary, then it may be actually make that revolutionary branch be
more than just talk.
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
Hello,
-----Original Message-----
From: Ferenc Kovacs [mailto:tyra3l@gmail.com]I see that the vote currently has swung from yes to no for including
in
5.6 but actually there is no option to include it even in PHP6? The
improvement is required, needs proper planning because of the impact
on many third parties, and should be planned now on the basis of a new
PHP6.Nobody said that if rejected this can't be considered for PHP6.
On the contrary, many of the no voters explained that they would have
voted yes if the target version would have been 6.0.This is not directed at you guys in particular, but this is just the
latest thread to mention PHP6 so I'll say it here. I know at least
my team is frustrated every time "why not PHP6?" is mentioned in
this thread.There is no PHP 6. If there was this RFC would have had two simple
options; merge for PHP 6.0, merge for both 5.6 & 6.0. The
justification for the latter option being that 5.6+ would provide a
more reasonable upgrade path for 6. It may not be meant this way,
but suggesting we merge this into PHP6 simply sounds disrespectful.
There's no point in targeting some ethereal release, that's just a
way of kicking this down the road so it can be ignored for a little
longer. Without a plan forward to a release, even merging to Master
is just another place for this to languish.And yes, I know there has been some (hopefully) serious discussion
on PHP6 recently, but that happens every year. Maybe it will happen
this time? IMHO, if PHP 5 has slipped happily into middle age and
cannot fathom such change anymore, then perhaps this community
should create a roadmap to a new branch where more progressive
development can be realized.Thanks,
Steve
If PHP 6 isn't branched/scheduled soon, then I would be in favor of
merging the feature to PHP 5.7.
However I do believe this change will be a good spring board for a PHP
6 branch, and I sense that talk about PHP 6 is serious at the moment.
This is why I'm don't view any "No" votes as disrespectful.
Chris
--
christopher.jones@oracle.com http://twitter.com/ghrd
Free PHP & Oracle book:
http://www.oracle.com/technetwork/topics/php/underground-php-oracle-manual-098250.html
On Fri, Jan 31, 2014 at 1:36 PM, Johannes Schlüter
johannes@schlueters.de wrote:
It is my understanding that part of the reason for the release workflow
RFC was that if patches miss the mark they don't have to wait for long
till the next release comes.In this case here we have 5.6.0alpaha1 out. Adding a major API change
touching each and every file can't be added to 5.6 anymore.Also the release process RFC says
x.y.z to x.y+1.z [...] ABI and API can be broken (internals), src compatibility should be kept if possible, while breakages are allowedThis rule contains many things that "can" and "should" and thus is open
to interprettation.
No, it is open to common sense and give us the opportunity to break
ABI if we like to in x.y+1. We did that in 5.4 and 5.5.
In my interpretation this rule is meant to allow
small changes, affecting only few extensions and where it would be
stupid to defer the.
To defer the ...?
And that's your interpretation, which is your good right. However the
release RFC allows us to introduce ABI breakages if desired and
accepted.
I think adding this patch to 5.x therefore would be quite some bending
of that rule and that combined with the fact that it is late makes me
believe that proposing this for 5.6 is illegal.
At least you did not loose your sense of humor.
Cheers,
Pierre
@pierrejoye | http://www.libgd.org
On Fri, Jan 31, 2014 at 1:36 PM, Johannes Schlüter
johannes@schlueters.de wrote:It is my understanding that part of the reason for the release workflow
RFC was that if patches miss the mark they don't have to wait for long
till the next release comes.In this case here we have 5.6.0alpaha1 out. Adding a major API change
touching each and every file can't be added to 5.6 anymore.Also the release process RFC says
x.y.z to x.y+1.z [...] ABI and API can be broken (internals), src compatibility should be kept if possible, while breakages are allowedThis rule contains many things that "can" and "should" and thus is open
to interprettation.No, it is open to common sense and give us the opportunity to break
ABI if we like to in x.y+1. We did that in 5.4 and 5.5.
So what is the purpose of the rule? If a "normal" RFC vote can do
whatever it likes why have that rule? As you are the author I'm happy to
learn your interpretation.
In my interpretation this rule is meant to allow
small changes, affecting only few extensions and where it would be
stupid to defer the.To defer the ...?
... the change.
At least you did not loose your sense of humor.
Yes, humor indeed helps if the one who creates the rules is also the one
who tries to bend it the most.
johannes
On Fri, Jan 31, 2014 at 2:27 PM, Johannes Schlüter
johannes@schlueters.de wrote:
So what is the purpose of the rule? If a "normal" RFC vote can do
whatever it likes why have that rule? As you are the author I'm happy to
learn your interpretation.
The RFC says that internals API and ABI can be broken in x.y+1. I have
no idea where it says that it can't. However it cannot be an
unilateral decision, why we have a RFC in this case f.e. unlike other
changes in 5.4 or 5.5.
In my interpretation this rule is meant to allow
small changes, affecting only few extensions and where it would be
stupid to defer the.To defer the ...?
... the change.
At least you did not loose your sense of humor.
Yes, humor indeed helps if the one who creates the rules is also the one
who tries to bend it the most.
First, there are many authors. Secondly this RFC follows every single
step of the RFC process and will do until the votes phase is over and
accept the results, no matter how they look.
--
Pierre
@pierrejoye | http://www.libgd.org
Am 31.01.2014 14:35, schrieb Pierre Joye:
First, there are many authors. Secondly this RFC follows every single
step of the RFC process and will do until the votes phase is over and
accept the results, no matter how they look.
Let's not forget that the core argument is one about the RFC /matters/
judged in the context of an accepted release process with regards to:
API/ABI changes in x.y+1 versions
As I see it, the RFC /process/ itself has never been questioned.
Ulf
On Fri, Jan 31, 2014 at 1:36 PM, Johannes Schlüter
johannes@schlueters.dewrote:
It is my understanding that part of the reason for the release workflow
RFC was that if patches miss the mark they don't have to wait for long
till the next release comes.In this case here we have 5.6.0alpaha1 out. Adding a major API change
touching each and every file can't be added to 5.6 anymore.Also the release process RFC says
x.y.z to x.y+1.z [...] ABI and API can be broken (internals), src compatibility should be kept if possible, while breakages are allowedThis rule contains many things that "can" and "should" and thus is open
to interprettation. In my interpretation this rule is meant to allow
small changes, affecting only few extensions and where it would be
stupid to defer the.I think adding this patch to 5.x therefore would be quite some bending
of that rule and that combined with the fact that it is late makes me
believe that proposing this for 5.6 is illegal.johannes
I think that calling it "illegal" is a bit streching it (because of the
lack of definitive wording of the releaseprocess RFC).
Personally I agree that this would be a pretty big BC break, and given the
fact that one of the goals of the new release process was to improve the
adoption rates of the new versions, plus the fact that it is more and more
likely that PHP-next(after 5.6) will be a major version where such change
has a better place, I've decided to vote no.
Based on the past experiences, I think if we accept the RFC, maybe we will
have enough time to stabilize the code to not miss the final release of
5.6.0, but there will be a bunch of widely used extensions out there, which
won't be supporting these changes for a while.
I would be happy if we could keep the discussion civil, even though that I
can understand the frustration of those who are really want this feature
ASAP or even contributed their time to make it happen.
For me, the most important thing is to not let this effort to be wasted,
even if it doesn't make it into 5.6, so as I mentioned in my previous
mails, I think it would be really important to have a major version on the
roadmap, so we can have these changes merged into an official branch where
there are more people watching and helping it stabilize.
--
Ferenc Kovács
@Tyr43l - http://tyrael.hu
On Fri, Jan 31, 2014 at 1:36 PM, Johannes Schlüter <johannes@schlueters.de
wrote:
It is my understanding that part of the reason for the release workflow
RFC was that if patches miss the mark they don't have to wait for long
till the next release comes.In this case here we have 5.6.0alpaha1 out. Adding a major API change
touching each and every file can't be added to 5.6 anymore.Also the release process RFC says
x.y.z to x.y+1.z [...] ABI and API can be broken (internals), src compatibility should be kept if possible, while breakages are allowedThis rule contains many things that "can" and "should" and thus is open
to interprettation. In my interpretation this rule is meant to allow
small changes, affecting only few extensions and where it would be
stupid to defer the.I think adding this patch to 5.x therefore would be quite some bending
of that rule and that combined with the fact that it is late makes me
believe that proposing this for 5.6 is illegal.johannes
I think that calling it "illegal" is a bit streching it (because of the
lack of definitive wording of the releaseprocess RFC).
Personally I agree that this would be a pretty big BC break, and given the
fact that one of the goals of the new release process was to improve the
adoption rates of the new versions, plus the fact that it is more and more
likely that PHP-next(after 5.6) will be a major version where such change
has a better place, I've decided to vote no.
Based on the past experiences, I think if we accept the RFC, maybe we will
have enough time to stabilize the code to not miss the final release of
5.6.0, but there will be a bunch of widely used extensions out there, which
won't be supporting these changes for a while.I would be happy if we could keep the discussion civil, even though that I
can understand the frustration of those who are really want this feature
ASAP or even contributed their time to make it happen.
For me, the most important thing is to not let this effort to be wasted,
even if it doesn't make it into 5.6, so as I mentioned in my previous
mails, I think it would be really important to have a major version on the
roadmap, so we can have these changes merged into an official branch where
there are more people watching and helping it stabilize.--
Ferenc Kovács
@Tyr43l - http://tyrael.hu
to clarify by BC break I meant internal API compatibility break of course,
so it would only affect the extension developers directly (and affecting
the users indirectly through the lack of extension support for the new
version).
--
Ferenc Kovács
@Tyr43l - http://tyrael.hu
https://wiki.php.net/rfc/size_t_and_int64
There was two big questions regarding the compatibility. Those open
questions appeared in the discussions are reflected in the reworked RFC.First question, the possibility to keep the old zend_parse_parameters()
specs 'l', 'L', 's', 'p' along with new 'i', 'I', 'S', 'P'. Keeping the old
zpp specs will for sure minimize the porting effort for the PECL
extensions, but might lead to confusion (like people might think ‘l’
still expects ‘long’ and not ‘php_int_t’). Please use the yes/no Vote 3 to
decide whether the ‘l’, ‘L’, ‘s’, ‘p’ have to stay supported.Second question, the macro renames for LONG<>INT, STRLEN<>STRSIZE, etc.
The reason for such renamings was to ensure source level incompatibility
on compile time. However this might have a negative effect on the porting
effort (despite the porting tools). Please use the yes/no Vote 2 to
decide whether the old macro names have to be kept.The Vote 1 is the main vote for this patch. The both Votes 2 and 3 are
merely to decide about the semantical replacements choosen for the patch.
Should the Votes 2 and 3 result in reverting of that semantical changes,
the essential patch part about the 64 bit support will not be hurt.
Reverting to old macro names or zpp specs is only the naming issue.Removal of the dead SAPIs is isolated in a separate RFC and can be
considered to another time.
The RFC was rejected.
Thanks for votes and constructive discussion. Based on the feedback in
this thread, this RFC will be resurrected anytime soon.
Best regards
Anatol
https://wiki.php.net/rfc/size_t_and_int64
There was two big questions regarding the compatibility. Those open
questions appeared in the discussions are reflected in the reworked RFC.First question, the possibility to keep the old zend_parse_parameters()
specs 'l', 'L', 's', 'p' along with new 'i', 'I', 'S', 'P'. Keeping the old
zpp specs will for sure minimize the porting effort for the PECL
extensions, but might lead to confusion (like people might think ‘l’
still expects ‘long’ and not ‘php_int_t’). Please use the yes/no Vote 3 to
decide whether the ‘l’, ‘L’, ‘s’, ‘p’ have to stay supported.Second question, the macro renames for LONG<>INT, STRLEN<>STRSIZE, etc.
The reason for such renamings was to ensure source level incompatibility
on compile time. However this might have a negative effect on the porting
effort (despite the porting tools). Please use the yes/no Vote 2 to
decide whether the old macro names have to be kept.The Vote 1 is the main vote for this patch. The both Votes 2 and 3 are
merely to decide about the semantical replacements choosen for the patch.
Should the Votes 2 and 3 result in reverting of that semantical changes,
the essential patch part about the 64 bit support will not be hurt.
Reverting to old macro names or zpp specs is only the naming issue.Removal of the dead SAPIs is isolated in a separate RFC and can be
considered to another time.The RFC was rejected.
Thanks for votes and constructive discussion. Based on the feedback in
this thread, this RFC will be resurrected anytime soon.Best regards
Anatol
Hi Anatol,
Thanks for all your work.
I look forward to a quick vote on whether to include it in PHP 5.7 or
PHP 6.0. However, it would be useful to first know the schedule of
those releases, and the branching strategy. It would be good to get
your patch into a branch that everyone is working on ASAP.
If your patch is approved for PHP 6.0 then I'm sure that you will be a
driving force in making sure PHP 6.0 stays on track. In fact, I can
foresee you becoming one of the PHP 6 RMs.
Chris
--
christopher.jones@oracle.com http://twitter.com/ghrd
Free PHP & Oracle book:
http://www.oracle.com/technetwork/topics/php/underground-php-oracle-manual-098250.html
On Feb 3, 2014 10:52 PM, "Christopher Jones" christopher.jones@oracle.com
wrote:
I look forward to a quick vote on whether to include it in PHP 5.7 or
PHP 6.0.
I do not think it is worth the effort to try it for 5.7. I have to say it
is hard to understand how you can think about 5.7 as well. Or are the
changes not so big?
Jokes apart, given the results 6 will be the target. That follows the
arguments against this RFC and we seriously hope that everyone will
participate earlier and will not bring the same arguments.
Cheers,
Pierre
Pierre Joye wrote:
Jokes apart, given the results 6 will be the target. That follows the
arguments against this RFC and we seriously hope that everyone will
participate earlier and will not bring the same arguments.
Hopefully reasons like this will polarise thinking on actually getting a PHP6
build underway, since the repackaging of Unicode has not driven that interest?
It is probably worth pointing out how many major versions some of the big
frameworks have gone through while PHP5.somthing has been their target, and that
these target different PHP5.x requirements. If PHP6 had not been pushed too
early would there have not been a different path from PHP5.3 anyway?
--
Lester Caine - G8HFL
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk
On Feb 3, 2014 10:52 PM, "Christopher Jones" christopher.jones@oracle.com
wrote:I look forward to a quick vote on whether to include it in PHP 5.7 or
PHP 6.0.I do not think it is worth the effort to try it for 5.7. I have to say it
is hard to understand how you can think about 5.7 as well. Or are the
changes not so big?Jokes apart, given the results 6 will be the target. That follows the
arguments against this RFC and we seriously hope that everyone will
participate earlier and will not bring the same arguments.
The RFC could need re-discussion and re-argumenting, anyway, if
accepted for PHP6, it should be merged very early in the branch so
that all the PHP6 base code will benefit from it ASAP.
Julien.P
On Feb 3, 2014 10:52 PM, "Christopher Jones" christopher.jones@oracle.com
wrote:I look forward to a quick vote on whether to include it in PHP 5.7 or
PHP 6.0.I do not think it is worth the effort to try it for 5.7. I have to say it
is hard to understand how you can think about 5.7 as well. Or are the
changes not so big?Jokes apart, given the results 6 will be the target. That follows the
arguments against this RFC and we seriously hope that everyone will
participate earlier and will not bring the same arguments.Cheers,
Pierre
-
There is no "effort", it would just be a voting option.
-
Some people may not want to wait for PHP 6 so they should be
allowed to vote for PHP 5.7 if they consider the BC issues
surmountable in a minor release. -
If a PHP 6 schedule doesn't finalize soon, then merging the
64-bit changes to PHP 5.7 may be the only way forward.
--
christopher.jones@oracle.com http://twitter.com/ghrd
Free PHP & Oracle book:
http://www.oracle.com/technetwork/topics/php/underground-php-oracle-manual-098250.html
On Tue, Feb 4, 2014 at 4:50 PM, Christopher Jones
christopher.jones@oracle.com wrote:
- There is no "effort", it would just be a voting option.
There is an effort as in this case the options will have to be
implemented. Besides the same discussions to be re do again about the
same issues.
- Some people may not want to wait for PHP 6 so they should be
allowed to vote for PHP 5.7 if they consider the BC issues
surmountable in a minor release.
These persons should have voted yes for 5.6 as the state is the same
as it is now (by the time of voting). And the time frame to fix the
few gotchas will be pretty much the same as well (2-3 months max).
- If a PHP 6 schedule doesn't finalize soon, then merging the
64-bit changes to PHP 5.7 may be the only way forward.
It will, oh believe me, it will.
Cheers,
Pierre
@pierrejoye | http://www.libgd.org