Everything
php
Learn Community Releases The PHP Project
Home » Project » Newsgroups » php.internals » [VOTE] 64 bit platform improvements for string length and integer »

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

php.internals

Anatoliy Belsky

12 years ago
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.

Nikita Popov

12 years ago
On Mon, Jan 27, 2014 at 9:15 PM, Anatol Belski <ab@php.net> 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. > > 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 6. Nikita

Pierre Joye

12 years ago
On Tue, Jan 28, 2014 at 9:23 PM, Nikita Popov <nikita.ppv@gmail.com> wrote:
> On Mon, Jan 27, 2014 at 9:15 PM, Anatol Belski <ab@php.net> 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. >> >> 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 > 6.
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

Nikita Popov

12 years ago
On Tue, Jan 28, 2014 at 9:33 PM, Pierre Joye <pierre.php@gmail.com> wrote:
> > 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 > > 6. > > 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

Christopher Jones

12 years ago
On 01/28/2014 12:51 PM, Nikita Popov wrote:
> On Tue, Jan 28, 2014 at 9:33 PM, Pierre Joye <pierre.php@gmail.com> wrote: > >>> 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 >>> 6. >> >> 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

Martin Keckeis

12 years ago
Am 28.01.2014 21:24 schrieb "Nikita Popov" <nikita.ppv@gmail.com>:
> > On Mon, Jan 27, 2014 at 9:15 PM, Anatol Belski <ab@php.net> 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. > > > > 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 > 6. > > Nikita
Sadly... (From a long waiting Php user, who dont want to wait 2-3 years...)

Christopher Jones

12 years ago
On 01/28/2014 12:36 PM, Martin Keckeis wrote:
> Am 28.01.2014 21:24 schrieb "Nikita Popov" <nikita.ppv@gmail.com>: >> >> On Mon, Jan 27, 2014 at 9:15 PM, Anatol Belski <ab@php.net> 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. >>> >>> 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 >> 6. >> >> 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

Jan Ehrhardt

12 years ago
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

Marc Bennewitz

12 years ago
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 On 27.01.2014 21:15, Anatol Belski wrote:

Anatol Belski

12 years ago
Hi Marc, thanks for the comments. On Thu, January 30, 2014 20:53, Marc Bennewitz wrote:
> 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

Derick Rethans

12 years ago
On Mon, 27 Jan 2014, Anatol Belski 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 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

Stas Malyshev

12 years ago
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...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.
-- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227

Pierre Joye

12 years ago
On Fri, Jan 31, 2014 at 1:42 AM, Stas Malyshev <smalyshev@sugarcrm.com> wrote:
> 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...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.
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

Stas Malyshev

12 years ago
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

Pierre Joye

12 years ago
On Sat, Feb 1, 2014 at 9:58 PM, Stas Malyshev <smalyshev@sugarcrm.com> wrote:
> 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

Stas Malyshev

12 years ago
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

Yasuo Ohgaki

12 years ago
Hi all, On Fri, Jan 31, 2014 at 9:42 AM, Stas Malyshev <smalyshev@sugarcrm.com>wrote:
> > 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

Christopher Jones

12 years ago
On 01/31/2014 01:31 PM, Yasuo Ohgaki 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. 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

Yasuo Ohgaki

12 years ago
Hi Christopher, On Sat, Feb 1, 2014 at 6:43 AM, Christopher Jones < christopher.jones@oracle.com> wrote:
> On 01/31/2014 01:31 PM, Yasuo Ohgaki 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

Anatoliy Belsky

12 years ago
On Fri, 2014-01-31 at 00:56 +0100, Derick Rethans wrote:
> On Mon, 27 Jan 2014, Anatol Belski 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

Derick Rethans

12 years ago
On Fri, 31 Jan 2014, Anatol Belski wrote:
> On Fri, 2014-01-31 at 00:56 +0100, Derick Rethans wrote: > > On Mon, 27 Jan 2014, Anatol Belski 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.
"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

Arvids Godjuks

12 years ago
2014-01-31 Derick Rethans <derick@php.net>:
> On Fri, 31 Jan 2014, Anatol Belski wrote: > > > On Fri, 2014-01-31 at 00:56 +0100, Derick Rethans wrote: > > > On Mon, 27 Jan 2014, Anatol Belski 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. > > "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.

Derick Rethans

12 years ago
On Fri, 31 Jan 2014, Arvids Godjuks wrote:
> 2014-01-31 Derick Rethans <derick@php.net>: > > > On Fri, 31 Jan 2014, Anatol Belski wrote: > > > > > > 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

Andrey Hristov

12 years ago
On 31.01.2014 13:30, Arvids Godjuks wrote:
> 2014-01-31 Derick Rethans <derick@php.net>: > >> On Fri, 31 Jan 2014, Anatol Belski wrote: >> >>> On Fri, 2014-01-31 at 00:56 +0100, Derick Rethans wrote: >>>> On Mon, 27 Jan 2014, Anatol Belski 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. >> >> "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

Pierre Joye

12 years ago
On Fri, Jan 31, 2014 at 12:56 AM, Derick Rethans <derick@php.net> wrote:
> 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

Derick Rethans

12 years ago
On Fri, 31 Jan 2014, Pierre Joye wrote:
> On Fri, Jan 31, 2014 at 12:56 AM, Derick Rethans <derick@php.net> wrote: > > > 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

Pierre Joye

12 years ago
On Fri, Jan 31, 2014 at 12:06 PM, Derick Rethans <derick@php.net> wrote:
> On Fri, 31 Jan 2014, Pierre Joye wrote: > >> On Fri, Jan 31, 2014 at 12:56 AM, Derick Rethans <derick@php.net> wrote: >> >> > 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

Christopher Jones

12 years ago
On 01/27/2014 12:15 PM, Anatol Belski 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. > > 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

Anatol Belski

12 years ago
Hi Chris, On Fri, January 31, 2014 01:38, Christopher Jones wrote:
>
> > On 01/27/2014 12:15 PM, Anatol Belski 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. >> >> >> 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

Nikita Popov

12 years ago
On Fri, Jan 31, 2014 at 9:26 PM, Anatol Belski <anatol.php@belski.net>wrote:
> > 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

Christopher Jones

12 years ago
On 01/31/2014 12:26 PM, Anatol Belski wrote:
> Hi Chris, > > On Fri, January 31, 2014 01:38, Christopher Jones wrote: >> > >> >> On 01/27/2014 12:15 PM, Anatol Belski 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. >>> >>> >>> 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

Derick Rethans

12 years ago
On Fri, 31 Jan 2014, Christopher Jones wrote:
> 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

Zeev Suraski

12 years ago
> 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

Pierre Joye

12 years ago
On Sat, Feb 1, 2014 at 7:28 PM, Zeev Suraski <zeev@zend.com> wrote:
>> 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

Johannes Schlueter

12 years ago
On Sat, 2014-02-01 at 19:35 +0100, Pierre Joye wrote:
> It is not, there is no change from user level but on windows and a 1-2 > other platforms with long being 32 bit in 64bit.
The current rule isn't precise, different interpretations are possible. I lean to the side that a big change to the APIs is comparable to a userland language change. I can see that this is read differently.
> 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

Pierre Joye

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

Johannes Schlueter

12 years ago
On Sat, 2014-02-01 at 20:30 +0100, Pierre Joye wrote:
> On Sat, Feb 1, 2014 at 8:11 PM, Johannes Schlüter > <johannes@schlueters.de> wrote: > > On Sat, 2014-02-01 at 19:35 +0100, Pierre Joye wrote: > >> It is not, there is no change from user level but on windows and a 1-2 > >> other platforms with long being 32 bit in 64bit. > > > > The current rule isn't precise, different interpretations are possible. > > I lean to the side that a big change to the APIs is comparable to a > > userland language change. I can see that this is read differently. > > > This section of the RFC aims to protect from not well designed > addition to the language, things affecting the long term maintenance > and its core design.
... like core API design ... ;-)
> To make the internals implementation and APIs more 64bit aware, safer, > cleaner and easier to deal with 64bit (compilation time check f.e.) is > not something covered by this section.
I understand your interpretation of the text, and going by the wording this might be correct, I still consider internal core APIs comparable.
> >> Also I find amazingly disturbing the amount of efforts you are putting > >> to shut down this RFC, without a single comment in the last months or > >> weeks, not even now to explain your vote. > >> > >> I do not mind a no, but what is happening here is disgusting, to say it nicely. > > > > Many contributors mentioned their concern about pushing in a patch > > changing more than 20,000 lines of code now. > > Stability of this patch has been proven. Work has began for months. > And if you look at the actual changes, they are much less problematic > than a couple of small patches having disturbing releases for ages, or > last minute addition of totally unstable extension, delaying release > and early adoption for months.
Even though it might be "proven" there are still issues, i.e. 21:53 < LawnGnome> cjones: /home/aharvey/trees/php-src/int64/ext/mysqli/mysqli_api.c:683:12: error: conflicting types for âmysqli_commit_or_rollback_libmysqlâ That one is most likely trivial (haven't done a libmysql build on that branch) to fix 22:05 <@johannes_> LawnGnome: should be a quite simple fix ... change mysqli_tx_cor_options_to_string and mysqli_commit_or_rollback_libmysql's signature touse the new type 22:06 < LawnGnome> johannes_: I'm sure you're right. I just disabled mysqli for now â I just want something I can phpize from so I can start seeing how good/bad/otherwise porting an extension to this is going to be for myself. but there likely are other small oversights.
> >I haven't seen much critic > > on the implementation itself, simply the request for more time to > > a) review it to make sure there are no accidental errors from conversion > > and > > 99% of the implementation and options about it have been around for > literally months. Sorry, this argument is totally invalid.
I comment on that further down in my previous message.
> > b) time to learn "the new way" before putting in a release, many have to > > relearn thins hardwired in the brain for more than 10 years, such > > adoption takes some time. > > I don't think anyone with little C experience needs more than 15mins > to understand the changes, given the extensively verbose and migration > guide.
The issue is not reading it, but current type choices I can quote when woken at night and made drunk. Adoption takes time.
> > Yes, we might have reviewed the branch sooner and learned the details > > sooner but we are lazy and holding back in investing time in > > "experimental" things. > > There is nothing experimental in this patch but a long awaited due > cleanup and safe changes. We have been talking about that for ages. > Our team finally took the beast by its horn and put a working, clean > and safe patch. They tested it, very early, constantly, provided > regular updates and requested feedback since months. I, personally, do > not buy the laziness and lack of time argument.
I've seen mostly messages appreciating the work.
> > I think a good way to proceed is to put it in master now and leave it > > from 5.6. This forces everybody to look into it (and we will have lots > > of opportunity to learn due to merging pain [which we have when putting > > in 5.6, too]) and gives everybody enough time to adopt their brain and > > prepare pecl (and internal) exts. > > That won't happen without another RFC and votes. We also drop all the > options as we are most likely targeting 6 anyway. I won't be surprised > to see the same arguments coming again btw :)
Most messages I have read and most chatter I have seen rejects not the patch itself but the strong pushing it in with this timing. I think acceptance for master would be there. (unless people have too much time and find actual technical issues, of which I'm not aware) johannes

Christopher Jones

12 years ago
On 2/1/14 10:35 AM, Pierre Joye wrote:
> On Sat, Feb 1, 2014 at 7:28 PM, Zeev Suraski <zeev@zend.com> wrote: >>> 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

Derick Rethans

12 years ago
On Sat, 1 Feb 2014, Pierre Joye wrote:
> On Sat, Feb 1, 2014 at 7:28 PM, Zeev Suraski <zeev@zend.com> wrote: > >> 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

Pierre Joye

12 years ago
On Mon, Feb 3, 2014 at 10:50 AM, Derick Rethans <derick@php.net> wrote:
> 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

Ulf Wendel

12 years ago
Am 01.02.2014 19:35, schrieb Pierre Joye:
> On Sat, Feb 1, 2014 at 7:28 PM, Zeev Suraski <zeev@zend.com> wrote: > 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

Johannes Schlueter

12 years ago
On Sat, 2014-02-01 at 20:28 +0200, Zeev Suraski wrote:
> > 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

Zeev Suraski

12 years ago
> -----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 integer > > On Sat, 2014-02-01 at 20:28 +0200, Zeev Suraski wrote: > > > 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%
Probably a clean good way to differentiate, sounds good to me. Zeev

Stas Malyshev

12 years ago
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

Derick Rethans

12 years ago
On Sat, 1 Feb 2014, Stas Malyshev wrote:
> > 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

Pierre Joye

12 years ago
On Mon, Feb 3, 2014 at 10:49 AM, Derick Rethans <derick@php.net> wrote:
> 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

Julien Pauli

12 years ago
On Mon, Feb 3, 2014 at 10:53 AM, Pierre Joye <pierre.php@gmail.com> wrote:
> On Mon, Feb 3, 2014 at 10:49 AM, Derick Rethans <derick@php.net> wrote: > >> 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

Derick Rethans

12 years ago
On Fri, 31 Jan 2014, Anatol Belski wrote:
> On Fri, January 31, 2014 01:38, Christopher Jones wrote:
> > 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

Johannes Schlueter

12 years ago
On Mon, 2014-01-27 at 21:15 +0100, Anatol Belski wrote:
> https://wiki.php.net/rfc/size_t_and_int64
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

Ulf Wendel

12 years ago
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

Johannes Schlueter

12 years ago
On Fri, 2014-01-31 at 13:41 +0100, Ulf Wendel 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. johannes

Pierre Joye

12 years ago
On Fri, Jan 31, 2014 at 1:55 PM, Johannes Schlüter <johannes@schlueters.de> wrote:
> On Fri, 2014-01-31 at 13:41 +0100, Ulf Wendel 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

Johannes Schlueter

12 years ago
On Fri, 2014-01-31 at 14:00 +0100, Pierre Joye wrote:
> On Fri, Jan 31, 2014 at 1:55 PM, Johannes Schlüter > <johannes@schlueters.de> wrote: > > On Fri, 2014-01-31 at 13:41 +0100, Ulf Wendel 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.
> FYI: https://wiki.php.net/todo/php56
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

Ulf Wendel

12 years ago
Am 31.01.2014 13:55, schrieb Johannes Schlüter:
> On Fri, 2014-01-31 at 13:41 +0100, Ulf Wendel 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.
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

Pierre Joye

12 years ago
On Fri, Jan 31, 2014 at 2:08 PM, Ulf Wendel <ulf.wendel@phpdoc.de> wrote:
> Am 31.01.2014 13:55, schrieb Johannes Schlüter: >> On Fri, 2014-01-31 at 13:41 +0100, Ulf Wendel 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. > > 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

Ulf Wendel

12 years ago
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

Zeev Suraski

12 years ago
> -----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 integer > > On Fri, 2014-01-31 at 13:41 +0100, Ulf Wendel 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.
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

Christopher Jones

12 years ago
On 01/31/2014 01:21 PM, Zeev Suraski 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. > > 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

Pierre Joye

12 years ago
On Fri, Jan 31, 2014 at 10:51 PM, Christopher Jones <christopher.jones@oracle.com> wrote:
> > > On 01/31/2014 01:21 PM, Zeev Suraski 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

Jakub Zelenka

12 years ago
On Fri, Jan 31, 2014 at 9:21 PM, Zeev Suraski <zeev@zend.com> wrote:
> > -----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 integer > > > > On Fri, 2014-01-31 at 13:41 +0100, Ulf Wendel 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. > > > 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

Pierre Joye

12 years ago
On Sat, Feb 1, 2014 at 1:04 PM, Jakub Zelenka <bukka@php.net> wrote:
> 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

Lester Caine

12 years ago
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

Ferenc Kovacs

12 years ago
On Sat, Feb 1, 2014 at 2:27 PM, Lester Caine <lester@lsces.co.uk> wrote:
> 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

Lester Caine

12 years ago
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

Stephen Zarkos

12 years ago
Hello,
> -----Original Message----- > From: Ferenc Kovacs [mailto:tyra3l@gmail.com] > > On Sat, Feb 1, 2014 at 2:27 PM, Lester Caine <lester@lsces.co.uk> wrote: > > > > > 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

Pierre Joye

12 years ago
On Fri, Jan 31, 2014 at 1:36 PM, Johannes Schlüter <johannes@schlueters.de> wrote:
> On Mon, 2014-01-27 at 21:15 +0100, Anatol Belski wrote: >> https://wiki.php.net/rfc/size_t_and_int64 > > 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.
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

Johannes Schlueter

12 years ago
On Fri, 2014-01-31 at 13:51 +0100, Pierre Joye wrote:
> On Fri, Jan 31, 2014 at 1:36 PM, Johannes Schlüter > <johannes@schlueters.de> wrote: > > On Mon, 2014-01-27 at 21:15 +0100, Anatol Belski wrote: > >> https://wiki.php.net/rfc/size_t_and_int64 > > > > 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. > > 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

Pierre Joye

12 years ago
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

Ulf Wendel

12 years ago
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

Ferenc Kovacs

12 years ago
On Fri, Jan 31, 2014 at 1:36 PM, Johannes Schlüter <johannes@schlueters.de>wrote:
> On Mon, 2014-01-27 at 21:15 +0100, Anatol Belski wrote: > > https://wiki.php.net/rfc/size_t_and_int64 > > 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 > >
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

Ferenc Kovacs

12 years ago
On Fri, Jan 31, 2014 at 5:19 PM, Ferenc Kovacs <tyra3l@gmail.com> wrote:
> > > > On Fri, Jan 31, 2014 at 1:36 PM, Johannes Schlüter <johannes@schlueters.de > > wrote: > >> On Mon, 2014-01-27 at 21:15 +0100, Anatol Belski wrote: >> > https://wiki.php.net/rfc/size_t_and_int64 >> >> 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 >> >> > 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

Anatol Belski

12 years ago
On Mon, January 27, 2014 21:15, Anatol Belski 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. > > 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

Christopher Jones

12 years ago
On 02/03/2014 01:10 PM, Anatol Belski wrote:
> On Mon, January 27, 2014 21:15, Anatol Belski 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. >> >> 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

Pierre Joye

12 years ago
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

Lester Caine

12 years ago
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

Julien Pauli

12 years ago
On Tue, Feb 4, 2014 at 6:33 AM, Pierre Joye <pierre.php@gmail.com> wrote:
> 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

Christopher Jones

12 years ago
On 2/3/14 9:33 PM, Pierre Joye wrote:
> 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 >
1. There is no "effort", it would just be a voting option. 2. 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. 3. 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

Pierre Joye

12 years ago
On Tue, Feb 4, 2014 at 4:50 PM, Christopher Jones <christopher.jones@oracle.com> wrote:
> 1. 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.
> 2. 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).
> 3. 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