Re: [PHP-DEV] Passing specific bison to build
On Wed, Jul 17, 2013 at 4:00 AM, Yasuo Ohgaki yohg...@ohgaki.net wrote: Hi all, I've upgraded to Fedora 19 and bison is too new for PHP 5.4/5.3 I would like to users to select specific bison to build with. --- a/Zend/acinclude.m4 +++ b/Zend/acinclude.m4 @@ -12,7 +12,7 @@ AC_DEFUN([LIBZEND_BISON_CHECK],[ bison_version=none if test $YACC; then AC_CACHE_CHECK([for bison version], php_cv_bison_version, [ - bison_version_vars=`bison --version 2 /dev/null | grep 'GNU Bison' | cut -d ' ' -f 4 | + bison_version_vars=`$YACC --version 2 /dev/null | grep 'GNU Bison' | cut -d ' ' -f 4 | php_cv_bison_version=invalid if test -n $bison_version_vars; then set $bison_version_vars To build with specific bison, you may do YACC=/usr/local/bin/bison1 ./configure Any comments? +1. Would be very useful for RMing as well, as we have to test different bison versions and use one for RMing which may not be the system's one. Julien.Pauli
[PHP-DEV] Pull requests report (17/7/2013)
Merged requests (past 7 days): #364 https://github.com/php/php-src/pull/364 fix invalid variable name at ext/spl/internal/multipleiterator.inc #370 https://github.com/php/php-src/pull/370 Remove PWS (Personal Web Server) references #377 https://github.com/php/php-src/pull/377 Add built-in web server to cli usage, and align terminology in cli manpage #378 https://github.com/php/php-src/pull/378 Fix bug #62665https://bugs.php.net/bug.php?id=62665: add curl.cainfo to php.ini #386 https://github.com/php/php-src/pull/386 Typo fixes Thanks Stas for helping these merges happen. New (last 7 days): #384 https://github.com/php/php-src/pull/384 HASH_KEY_NON_EXISTANT typo fix #385 https://github.com/php/php-src/pull/385 mssql.compatability_mode typo fix #387 https://github.com/php/php-src/pull/387 Wrong value for FILTER_SANITIZE_FULL_SPECIAL_CHARS existing (7-14 days): #375 https://github.com/php/php-src/pull/375 Fixed bug #48770https://bugs.php.net/bug.php?id=48770: when call_user_func() fails to call parent from inheriting class #381 https://github.com/php/php-src/pull/381 Fixed #65225https://bugs.php.net/bug.php?id=65225: PHP_BINARY incorrectly set #382 https://github.com/php/php-src/pull/382 Added support for not canonicalizing the SASL realm on sasl_binds for LDAP What do you think about closing older PR ( 28 days) ? Kaplan On Wed, Jul 10, 2013 at 3:36 PM, Lior Kaplan lio...@zend.com wrote: Hi, Following my suggestion to help with pull requests, I'm going to send a report about new ongoing pull requests. I hope it will help us to handle them more efficiently and lower the response time for patches. Feedback is much appriciated. New (last 7 days): #375 https://github.com/php/php-src/pull/375 Fixed bug #48770https://bugs.php.net/bug.php?id=48770: when call_user_func() fails to call parent from inheriting class #377 https://github.com/php/php-src/pull/377 Add built-in web server to cli usage, and align terminology in cli manpage #378 https://github.com/php/php-src/pull/378 Fix bug #62665https://bugs.php.net/bug.php?id=62665: add curl.cainfo to php.ini #381 https://github.com/php/php-src/pull/381 Fixed #65225https://bugs.php.net/bug.php?id=65225: PHP_BINARY incorrectly set #382 https://github.com/php/php-src/pull/382 Added support for not canonicalizing the SASL realm on sasl_binds for LDAP Older (but seems trivial): #360 https://github.com/php/php-src/pull/360 Use in preg_replace_callback() using variables by reference and test for bug # 64979 https://bugs.php.net/bug.php?id=64979 #364 https://github.com/php/php-src/pull/364 fix invalid variable name at ext/spl/internal/multipleiterator.inc #370 https://github.com/php/php-src/pull/370 Remove PWS (Personal Web Server) references Kaplan p.s. Feel free to just approve the merge after reviewing the code, and I'll do merge myself later.
Re: [PHP-DEV] Pull requests report (17/7/2013)
Hi! What do you think about closing older PR ( 28 days) ? I think we shouldn't do this - some of them are for RFCs that are being worked on or discussed or proposed, so unless we know it's a stale patch that is abandoned or will never be merged we shouldn't close them. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Pull requests report (17/7/2013)
First of all, thank you Lior for sending this out. Second, thanks Stas for looking over these. What do you think about closing older PR ( 28 days) ? I think we shouldn't do this - some of them are for RFCs that are being worked on or discussed or proposed, so unless we know it's a stale patch that is abandoned or will never be merged we shouldn't close them. This is definitely a good reason not to close old Pull Requests.
Re: [PHP-DEV] Pull requests report (17/7/2013)
On Wed, Jul 17, 2013 at 6:47 PM, Lior Kaplan lio...@zend.com wrote: Merged requests (past 7 days): #364 https://github.com/php/php-src/pull/364 fix invalid variable name at ext/spl/internal/multipleiterator.inc #370 https://github.com/php/php-src/pull/370 Remove PWS (Personal Web Server) references #377 https://github.com/php/php-src/pull/377 Add built-in web server to cli usage, and align terminology in cli manpage #378 https://github.com/php/php-src/pull/378 Fix bug #62665https://bugs.php.net/bug.php?id=62665: add curl.cainfo to php.ini #386 https://github.com/php/php-src/pull/386 Typo fixes Thanks Stas for helping these merges happen. New (last 7 days): #384 https://github.com/php/php-src/pull/384 HASH_KEY_NON_EXISTANT typo fix #385 https://github.com/php/php-src/pull/385 mssql.compatability_mode typo fix #387 https://github.com/php/php-src/pull/387 Wrong value for FILTER_SANITIZE_FULL_SPECIAL_CHARS existing (7-14 days): #375 https://github.com/php/php-src/pull/375 Fixed bug #48770https://bugs.php.net/bug.php?id=48770: when call_user_func() fails to call parent from inheriting class #381 https://github.com/php/php-src/pull/381 Fixed #65225https://bugs.php.net/bug.php?id=65225: PHP_BINARY incorrectly set #382 https://github.com/php/php-src/pull/382 Added support for not canonicalizing the SASL realm on sasl_binds for LDAP What do you think about closing older PR ( 28 days) ? First off, thanks for all the hard work. PRs aren't getting as much attention as they should, and I'd like to say that I certainly haven't been helping as much as I should with them. What I am noticing though, is that a lot of these newer PRs, or the ones that are getting more attention, seem to be fairly cosmetic changes. I mean, spelling mistakes are all great fixes, and no disrespect to any contribution small or big, but there are certainly a lot of PRs which people have spent a great deal of time working on, clearly, that seem to be getting ignored. If we start closing these strictly because of how long they've been open it would be such a discouragement to everyone who contributed. I sincerely hope this doesn't happen. I'd much rather see people spending more time on reviewing some of the older PRs and seeing if they're worthy of merging or not based on substance rather than just dismiss them based on how long they've been open. I've tried to get in contact with some of the original authors of at least a couple of PRs in the past weeks to see if they were interested in working on an RFC to get their PRs merged as they necessitated some more discussion, but so far have come up empty. So I'll try to help out as much as I can with the ones that can get immediate attention.
Re: [PHP-DEV] Pull requests report (17/7/2013)
Hi Sherif, 2013/7/18 Sherif Ramadan theanomaly...@gmail.com First off, thanks for all the hard work. PRs aren't getting as much attention as they should, and I'd like to say that I certainly haven't been helping as much as I should with them. We may have bugs ML and PR ML so that any discussion, then it may have more attentions. Bugs ML may have too many mails, but PR ML would have much less mails. It may be good idea that redirect PR discussion to internals, if it is possible. Regards, -- Yasuo Ohgaki yohg...@ohgaki.net
Re: [PHP-DEV] Pull requests report (17/7/2013)
Hi all, 2013/7/18 Yasuo Ohgaki yohg...@ohgaki.net 2013/7/18 Sherif Ramadan theanomaly...@gmail.com First off, thanks for all the hard work. PRs aren't getting as much attention as they should, and I'd like to say that I certainly haven't been helping as much as I should with them. We may have bugs ML and PR ML so that any discussion, then it may have more attentions. Bugs ML may have too many mails, but PR ML would have much less mails. It may be good idea that redirect PR discussion to internals, if it is possible. We already have Bugs ML http://www.php.net/mailing-lists.php I subscribed it now. For github, there is notification, but apparently not many people pay attention. -- Yasuo Ohgaki yohg...@ohgaki.net
[PHP-DEV] Fixes for documentation in source. Which branch to start?
Hi all, Take a look at this PR https://github.com/php/php-src/pull/351.diff The documentation in php.ini-* is broken, where should we fix these kind of error? From 5.3 branch or 5.4 branch? Thank you. -- Yasuo Ohgaki yohg...@ohgaki.net
Re: [PHP-DEV] Pull requests report (17/7/2013)
On Wed, Jul 17, 2013 at 11:21 PM, Yasuo Ohgaki yohg...@ohgaki.net wrote: Hi Sherif, 2013/7/18 Sherif Ramadan theanomaly...@gmail.com First off, thanks for all the hard work. PRs aren't getting as much attention as they should, and I'd like to say that I certainly haven't been helping as much as I should with them. We may have bugs ML and PR ML so that any discussion, then it may have more attentions. Bugs ML may have too many mails, but PR ML would have much less mails. It may be good idea that redirect PR discussion to internals, if it is possible. Well, some people may not be paying attention to the discussion on github about certain PRs and that's OK. Some people may not fully understand or have enough knowledge in one particular area to be able to help with that PR. Perfectly fine. However, I don't think that THIS is the reason PRs aren't getting their fair share of attention, honestly. For example, look at the oldest PR sitting around for over a year now https://github.com/php/php-src/pull/15 plenty of discussion there. Lots of criticism, suggestions, etc... All of that is wonderful. People are participating! Then all of a sudden the people involved in the discussion seem to mysteriously disappear and nothing happens to the PR. It just sits in limbo indefinitely. This is not the only PR I've seen follow this pattern. I assure you the discussion on github and the mailing lists are not the reason we've got stagnate PRs.
Re: [PHP-DEV] Fixes for documentation in source. Which branch to start?
On Wed, Jul 17, 2013 at 11:55 PM, Yasuo Ohgaki yohg...@ohgaki.net wrote: Hi all, Take a look at this PR https://github.com/php/php-src/pull/351.diff The documentation in php.ini-* is broken, where should we fix these kind of error? From 5.3 branch or 5.4 branch? 5.3 is security fixes only.
Re: [PHP-DEV] Fixes for documentation in source. Which branch to start?
Hi Sherif, 2013/7/18 Sherif Ramadan theanomaly...@gmail.com 5.3 is security fixes only. It may be good idea keep basic principle for docs, too. I've committed from PHP 5.4. Regards, -- Yasuo Ohgaki yohg...@ohgaki.net
[PHP-DEV] Re: Passing specific bison to build
Hi Johannes, 2013/7/17 Yasuo Ohgaki yohg...@ohgaki.net --- a/Zend/acinclude.m4 +++ b/Zend/acinclude.m4 @@ -12,7 +12,7 @@ AC_DEFUN([LIBZEND_BISON_CHECK],[ bison_version=none if test $YACC; then AC_CACHE_CHECK([for bison version], php_cv_bison_version, [ - bison_version_vars=`bison --version 2 /dev/null | grep 'GNU Bison' | cut -d ' ' -f 4 | + bison_version_vars=`$YACC --version 2 /dev/null | grep 'GNU Bison' | cut -d ' ' -f 4 | php_cv_bison_version=invalid if test -n $bison_version_vars; then set $bison_version_vars To build with specific bison, you may do YACC=/usr/local/bin/bison1 ./configure Would you commit this patch from PHP 5.3? It may be easier for us to maintain PHP 5.3 with this. Thank you. -- Yasuo Ohgaki yohg...@ohgaki.net
Re: [PHP-DEV] Fixes for documentation in source. Which branch to start?
On Thu, Jul 18, 2013 at 6:19 AM, Sherif Ramadan theanomaly...@gmail.com wrote: On Wed, Jul 17, 2013 at 11:55 PM, Yasuo Ohgaki yohg...@ohgaki.net wrote: Hi all, Take a look at this PR https://github.com/php/php-src/pull/351.diff The documentation in php.ini-* is broken, where should we fix these kind of error? From 5.3 branch or 5.4 branch? 5.3 is security fixes only. Well, I don't see a good enough reason not to commit documentation to 5.3 as well -- Pierre @pierrejoye | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
