Re: [PHP-DEV] Re: [PHP-CVS] com php-src: fix CG(empty_string) init in ZTS: Zend/zend.c
Hi Anatol, I didn't completely get your ideas, but if tsrm_ls_cache can't be exported on Windows directly, can we have a copy of tsrm_ls_cache in each DLL/EXE and initialize it once? Thanks. Dmitry. On Sun, Sep 21, 2014 at 9:19 PM, Anatol Belski anatol@belski.net wrote: Hi Dmitry, On Sat, September 20, 2014 09:58, Anatol Belski wrote: Hi Dmitry, On Fri, September 19, 2014 12:43, Dmitry Stogov wrote: I know :) Interned strings in PHP5 were implemented as characters allocated in one single buffer. Adding new strings into this buffer from different threads would require synchronization (locks). In PHP7 this implementation was changed. So it's probably must be possible to use interned strings in ZTS now. If we use separate HashTables for interned strings in different threads we may share some common part of predefined interned strings and have new interned strings in each thread independently. I'm not sure if it'll work well with opcache, because it substitutes interned strings handling mechanism to use shared memory. May be it'll work out of the box. BTW: I'm not interested in implementing this myself. Also, if we really like ZTS, may be PHP7 is the time to switch to native TLS and remove all these TSRMLS macros. Even if it won't allow to run ZTS on some platforms, it won't be the end of the world, because ZTS is not really widely used now. I won't be able to work on it actively, but I may provide some help. Thanks. Dmitry. maybe it'd make sense to do it the other way round. First get rid of TSRM, than look what is doable with interned strings? I'd be sure in the game, if there are enough interested people to actively do that. yesterday Joe pushed the approach on the TSRMLS_* removal subject http://git.php.net/?p=php-src.git;a=shortlog;h=refs/heads/native-tls While trying to port it for Windows, I see some design issues and have an idea how to solve it. The patch is relying on a few things which Visual Studio cannot handle. The first one: TSRM_API extern TSRM_TLS void *tsrm_ls_cache; but exporting the TSRM cache from a DLL won't work with VS. There it would look like __declspec(dllexport) extern __declspec(thread) void *tsrm_ls_cache; VS linker cannot share variables directly between DLL and EXE. Furthermore, even bigger issue could be with modules loaded on runtime. The second issue is that while ini entries are defined in static arrays, when they link to some SAPI or extension globals, they would have an id passed. That Id would be declared like __declspec(dllimport) ts_rsrc_id cli_server_globals_id; While passed to the ini entry by reference, it's still not a constant value. So VS refuses to initialize an ini entry with something not from the constant extent (AFAIK that's ok for C89). That's for the issues. How to solve them - after some research it looks like one can share thread data using getter/setter functions (using DLL_THREAD_ATTACH event in DllMain to initialize current thread data). That would probably require some more rewrites in the code. The main question, whether the negative impact because of having to do the extra function calls would make such porting senseless. The flow were like apache (or php) binary starts thread TSRM layer inits TLS data php inits globals / depend on TSRM layer extensions init/read globals / depend on TSRM layer That's just a basic idea yet. For the second issue - some similar approach. Instead of using some_globals_id, one could replace it with a function pointer so then it can deliver the right location by thread. What do you think about my solution ideas? Maybe also there was some other approaches we didn't take in account yet? Depending on whether we can use the function calls, maybe it'd even make sense to make something like libtsrm to incapsulate all the TS features. Thanks Anatol
Re: [PHP-DEV] [RFC] Change checkdnsrr() $type argument behavior
hi Kris, On Sat, Sep 20, 2014 at 4:15 AM, Kris Craig kris.cr...@gmail.com wrote: Per discussion in an earlier thread. Here's the RFC: https://wiki.php.net/rfc/checkdnsrr-default-type Basically, this RFC seeks to make it so that PHP's checkdnsrr() function, which is most commonly used to see whether or not a hostname exists, no longer restricts itself to only MX records by default. Though the RFC itself is a no-brainer, the more difficult question is which solution should be implemented. The two options currently presented are changing default from MX to ANY, which would cause it to check all records and not just MX; and getting rid of the default altogether and making it so that the argument is required. From what I can tell, there are valid arguments to be made for both, so I would love to see some discussion/debate here regarding which solution should be implemented, as I'm currently undecided. Also please feel free to point out any areas of improvement for the RFC itself. I am not sure which problem this RFC tries to solve, do you have any example showing the issues please? Cheers, -- Pierre @pierrejoye | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] #68049 filter_var echo wrong result for a url
Some browsers do. Some versions of IE are buggy when the URL include underscores: http://stackoverflow.com/questions/794243/internet-explorer-ignores-cookies-on-some-domains-cannot-read-or-set-cookies I think that filter_var must follow the RFC by default. Maybe can we add a flag to allow malformed URL in use in the wild? 2014-09-21 10:42 GMT+02:00 Florian Margaine flor...@margaine.com: Hi, According to https://bugs.php.net/bug.php?id=51192 , valid URLs cannot contain underscores. The following bug was reported a couple days ago: https://bugs.php.net/bug.php?id=68049 The thing is, browsers *do* accept the underscore in URLs. Should the rfc3986 http://tools.ietf.org/html/rfc3986#section-3.2.2 be respected, or should PHP be lenient like browsers and accept more? Regards, *Florian Margaine* -- Kévin Dunglas Consultant et développeur freelance http://dunglas.fr Tél. : 06 60 91 20 20
Re: [PHP-DEV] [RFC] Change checkdnsrr() $type argument behavior
On Sep 21, 2014 11:52 PM, Pierre Joye pierre@gmail.com wrote: hi Kris, On Sat, Sep 20, 2014 at 4:15 AM, Kris Craig kris.cr...@gmail.com wrote: Per discussion in an earlier thread. Here's the RFC: https://wiki.php.net/rfc/checkdnsrr-default-type Basically, this RFC seeks to make it so that PHP's checkdnsrr() function, which is most commonly used to see whether or not a hostname exists, no longer restricts itself to only MX records by default. Though the RFC itself is a no-brainer, the more difficult question is which solution should be implemented. The two options currently presented are changing default from MX to ANY, which would cause it to check all records and not just MX; and getting rid of the default altogether and making it so that the argument is required. From what I can tell, there are valid arguments to be made for both, so I would love to see some discussion/debate here regarding which solution should be implemented, as I'm currently undecided. Also please feel free to point out any areas of improvement for the RFC itself. I am not sure which problem this RFC tries to solve, do you have any example showing the issues please? Cheers, -- Pierre @pierrejoye | http://www.libgd.org It's not a bug or anything. The problem is that the current behavior is very counter-intuitive, not to mention unnecessary because there's already another function dedicated to MX lookups. At my job, we wasted a good deal of time troubleshooting what appeared to be a weird DNS issue that turned out to just be a checkdnsrr() lookup that was looking only for MX records because a second argument wasn't passed. I cannot think of any use case served by this behavior. --Kris
Re: [PHP-DEV] #68049 filter_var echo wrong result for a url
Oh, IE. *sigh* Adding a new flag sounds like a good idea indeed, `FILTER_VALIDATE_UNCOMPLIANT_URL` sounds good enough? I guess it should accept underscores and domain names starting with numbers too. Regards, *Florian Margaine* P.S: sorry Kevin for the double mail. Le 22 sept. 2014 09:03, Kévin Dunglas dung...@gmail.com a écrit : Some browsers do. Some versions of IE are buggy when the URL include underscores: http://stackoverflow.com/questions/794243/internet-explorer-ignores-cookies-on-some-domains-cannot-read-or-set-cookies I think that filter_var must follow the RFC by default. Maybe can we add a flag to allow malformed URL in use in the wild? 2014-09-21 10:42 GMT+02:00 Florian Margaine flor...@margaine.com: Hi, According to https://bugs.php.net/bug.php?id=51192 , valid URLs cannot contain underscores. The following bug was reported a couple days ago: https://bugs.php.net/bug.php?id=68049 The thing is, browsers *do* accept the underscore in URLs. Should the rfc3986 http://tools.ietf.org/html/rfc3986#section-3.2.2 be respected, or should PHP be lenient like browsers and accept more? Regards, *Florian Margaine* -- Kévin Dunglas Consultant et développeur freelance http://dunglas.fr Tél. : 06 60 91 20 20
RE: [PHP-DEV] [RFC] Loop... or...
From: Leigh [mailto:lei...@gmail.com] Sent: Friday, September 19, 2014 11:57 PM
Traditionally this is requested as a loop {} else {} structure,
however due to the choice of keyword this causes significant BC
problems.
I have written an RFC presenting this feature as loop {} or {} along
with how I intend to implement it. I have consulted with several core
contributors as well as normal developers, and this seems to be the
most BC-complete option.
I like this proposal as I am using this feature in Twig very often.
But I would really prefer using else instead of or, because it
is already common in the mentioned projects.
Maybe you could reconsider if it is really not possible to use else.
What about making the brackets for the loop block obligatory for
using this feature?
Christian
Re: [PHP-DEV] Internationalized Domain Name support in FILTER_VALIDATE_URL
I'll implement optional (and not default) support of IDN in filter_var(). Does anyone known if it's better to use libIDN (LGPL) or ICU (custom license deviated from the X license) from a license point of view? 2014-09-19 16:18 GMT+02:00 Chris Wright c...@daverandom.com: On 19 September 2014 14:48, Kévin Dunglas dung...@gmail.com wrote: Support of IDN in streams is a must have. But there is a lot of other use cases for URL with IDN validation. The most common is probably form validation (test if an user submitted URL has a valid format and can be used to create an HTML link...). I'm ok making IDN validation optional and not used by default until PHP natively support IDN in other features such as streams. But IDN are used more and more in the wild, and from a user point of view it is disappointing that a valid URL, working in browsers and even displayed by Google Search is not considered as a valid URL by a PHP-based website using filter_var() without a specific flag. Even some TLD are using non-ASCII characters, exemple: http://旅游气象.中国 http://xn--zfv73l7xbp87c.xn--fiqs8s (popular Chinese weather site). About the library, I've not preference between libidn and icu. If the licence is libidn fit better with the PHP one, libidn is probably the better choice. Having a PHP specific implementation of STRINGPREP and Punnycode sounds not like a good idea (reinventing the wheel, more code to maintain). Chris, is there a chance to have your work on streams merged in PHP 7? It's very hacky and PoC at the moment. I've got a bunch of time-consuming personal things going on right now, but within the next couple of weeks I will try and polish it up into something serviceable, maintainable and tested/less likely to explode with edge-cases and then I'll put it up for discussion. I'm also fine if someone else wants to have a crack in the meantime, I can push my work so far to github early next week when I get access to the machine. I'd certainly like the functionality to be in 7 if it's viable from a licensing and dependency PoV - I had been holding off bringing it up to see what happened with the more general unicode support discussion (which I somewhat lost track of and seems to have died out) as there was talk of introducing a hard dependency on ICU-or-similar at one point, which would have made this a no-brainer. What do you thing about the following planning: - 5.7 (if exists): add IDN support in filter disabled by default. Use libidn if selected to be used for streams too. - 7 (if IDN support for streams is completed): validate IDN by default (what the user expect), add a flag to disable IDN validation. Of course we'll update the doc explaining the new behavior. 2014-09-19 12:28 GMT+02:00 Chris Wright c...@daverandom.com: On 19 September 2014 10:58, Pierre Joye pierre@gmail.com wrote: Hi, On Sep 19, 2014 4:03 PM, Chris Wright c...@daverandom.com wrote: Kévin On 18 September 2014 21:26, Kévin Dunglas dung...@gmail.com wrote: Hello, I'm working on enhancing the FILTER_VALIDATE_URL filter ( https://github.com/php/php-src/pull/826). The current implementation does not support validation of internationalized domain names (i.e: http://www.académie-française.fr/ http://www.xn--acadmie-franaise-npb1a.fr/ http://www.xn--acadmie-franaise-npb1a.fr/). Support of IDN validation can be easily added using ICU's uidna_toASCII() function. Is it acceptable to add a dependency to ICU for ext/filter? Another option is to add a HAVE_ICU constant in main/php_config.h and to validate IDN only if ICU is present. What strategy is preferred? I've done some work around this area previously, and all I will say is: be careful with what you do with this from a userland PoV. PHP does not natively support IDN in stream open routines or SSL verification routines. It will never support these things without at least one of: - a core dependency on ICU, libidn or similar - moving streams into an extension so a dependency can be introduced there (probably not sanely possible) - an in-house NAMEPREP implementation (this is the hard part of IDN, punycode itself is pretty trivial to implement once you have a canonical set of codepoints) These things can be implemented with *a lot* of boilerplate in userland when you have ext/intl, but it's not pretty. libcurl *can* support IDN if it was built against libidn, I'm not sure if this is currently the case in common distributions or not. Since one almost never just validates a URL string, it's usually a precursor to attempting to open it, this could lead to some pretty hefty wtfs. In short, while I'm generally for ext/filter being able to handle IDN, I *do not* believe it should do it implicitly, it should require an explicit flag, because it will
Re: [PHP-DEV] #68049 filter_var echo wrong result for a url
I've recently proposed a refactoring of FILTER_VALIDATE_URL: https://github.com/php/php-src/pull/826 I can easily add the support of this new flag is everyone agree. 2014-09-22 9:09 GMT+02:00 Florian Margaine flor...@margaine.com: Oh, IE. *sigh* Adding a new flag sounds like a good idea indeed, `FILTER_VALIDATE_UNCOMPLIANT_URL` sounds good enough? I guess it should accept underscores and domain names starting with numbers too. Regards, *Florian Margaine* P.S: sorry Kevin for the double mail. Le 22 sept. 2014 09:03, Kévin Dunglas dung...@gmail.com a écrit : Some browsers do. Some versions of IE are buggy when the URL include underscores: http://stackoverflow.com/questions/794243/internet-explorer-ignores-cookies-on-some-domains-cannot-read-or-set-cookies I think that filter_var must follow the RFC by default. Maybe can we add a flag to allow malformed URL in use in the wild? 2014-09-21 10:42 GMT+02:00 Florian Margaine flor...@margaine.com: Hi, According to https://bugs.php.net/bug.php?id=51192 , valid URLs cannot contain underscores. The following bug was reported a couple days ago: https://bugs.php.net/bug.php?id=68049 The thing is, browsers *do* accept the underscore in URLs. Should the rfc3986 http://tools.ietf.org/html/rfc3986#section-3.2.2 be respected, or should PHP be lenient like browsers and accept more? Regards, *Florian Margaine* -- Kévin Dunglas Consultant et développeur freelance http://dunglas.fr Tél. : 06 60 91 20 20 -- Kévin Dunglas Consultant et développeur freelance http://dunglas.fr Tél. : 06 60 91 20 20
[PHP-DEV] Re: OpenSSL bug in 5.4.33 and 5.5.17
I noticed a regression in 5.5.17RC1, reported it (#67965) and it got fixed in f86b2193 on the 5.5 branch by Daniel Lowrey. But this fix didn't make it in 5.5.17 final. I posted the following message on the 5.5.17RC1 release announcement: What's the benefit of doing a Release Candidate/QA cycle when fixes for regressions aren't merged to the final release? See https://bugs.php.net/bug.php?id=67965 Regression reported and fixed, but fix not merged to 5.5.17 branch. Commit https://github.com/php/php-src/commit/f86b2193a483f56b0bd056570a0cdb57ebe66e2f?diff=unified File in 5.5.17: https://github.com/php/php-src/blob/PHP-5.5.17/ext/openssl/xp_ssl.c#L884 Not critical enough? Just missed it? RC releases just for the show? :? Who is resposible for cherrypicking fixes for regressions in release candidates? The release manager? The developer who commited the fix? Did the release manager ever considered including this fix in the final version? Where are regressions tracked? The issues tracker didn't have a 'PHP5.5.15RC1' version, so bugs are filled against '5.5Git-2014-09-05' which makes it difficult to track issues specific on 5.5.17RC1. PHP 5.6.1.RC1 however, IS listed as a version on https://bugs.php.net/report.php The releaseprocess RFC (https://wiki.php.net/rfc/releaseprocess) does not address these issues. Arjen On 09/19/2014 06:49 PM, Remi Collet wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Le 19/09/2014 18:25, Daniel Lowrey a écrit : In an effort to fix a very old (seven years old) DoS vulnerability involving encrypted streams I created a regression where feof() notifications on encrypted sockets are broken. This is present in both the most recent 5.4.33 and 5.5.17 releases. Can you please point us to the related commit... (which one cause the regression, which ones are useful) In 5.4.33 and 5.5.17 an immediate fix is to revert these commits: http://git.php.net/?p=php-src.git;a=commitdiff;h=6569db88081562f68a4f79e52cba83482bdf05fc http://git.php.net/?p=php-src.git;a=commitdiff;h=372844918a318ad712e16f9ec636682424a65403 http://git.php.net/?p=php-src.git;a=commitdiff;h=32be79dcfa1bc5af8682d9f512da68c5b3e2cbf3 The last of these (32be79d) has already been fixed upstream by f86b2193a483f56b0bd056570a0cdb57ebe66e2f but this change did not go into 5.4.33 and 5.5.17. Any reverts should also consider f86b2193. Does a revert of the first enough to get back to previous behavior? Yes, reverting the above commits above will fix any issues. I'm awaiting word from someone associated with Horde to verify that the previously linked patch ( https://bugs.php.net/patch-display.php?bug=41631patch=bug41631.patchrevision=1411139621) resolves the issue. As long as that works as expected I can merge that and everything should be resolved going forward. After a quick check 6569db8 and 32be79d are in 5.4.33 / 5.5.17 / 5.6.1RC1 f86b219 and 3728449 are in 5.6.1RC1 only -BEGIN PGP SIGNATURE- Version: GnuPG v2 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlQcXrUACgkQYUppBSnxahgfigCfUYmoYXJJYC0JKmLi/tg+mo1r mwwAoNXbDpPsdrVfzFWUy4tuOssqR256 =OUHp -END PGP SIGNATURE- -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] #68049 filter_var echo wrong result for a url
Sounds like a great idea! Don't forget to update https://bugs.php.net/bug.php?id=68049 when it'll be done. Regards, *Florian Margaine* On Mon, Sep 22, 2014 at 9:20 AM, Kévin Dunglas dung...@gmail.com wrote: I've recently proposed a refactoring of FILTER_VALIDATE_URL: https://github.com/php/php-src/pull/826 I can easily add the support of this new flag is everyone agree. 2014-09-22 9:09 GMT+02:00 Florian Margaine flor...@margaine.com: Oh, IE. *sigh* Adding a new flag sounds like a good idea indeed, `FILTER_VALIDATE_UNCOMPLIANT_URL` sounds good enough? I guess it should accept underscores and domain names starting with numbers too. Regards, *Florian Margaine* P.S: sorry Kevin for the double mail. Le 22 sept. 2014 09:03, Kévin Dunglas dung...@gmail.com a écrit : Some browsers do. Some versions of IE are buggy when the URL include underscores: http://stackoverflow.com/questions/794243/internet-explorer-ignores-cookies-on-some-domains-cannot-read-or-set-cookies I think that filter_var must follow the RFC by default. Maybe can we add a flag to allow malformed URL in use in the wild? 2014-09-21 10:42 GMT+02:00 Florian Margaine flor...@margaine.com: Hi, According to https://bugs.php.net/bug.php?id=51192 , valid URLs cannot contain underscores. The following bug was reported a couple days ago: https://bugs.php.net/bug.php?id=68049 The thing is, browsers *do* accept the underscore in URLs. Should the rfc3986 http://tools.ietf.org/html/rfc3986#section-3.2.2 be respected, or should PHP be lenient like browsers and accept more? Regards, *Florian Margaine* -- Kévin Dunglas Consultant et développeur freelance http://dunglas.fr Tél. : 06 60 91 20 20 -- Kévin Dunglas Consultant et développeur freelance http://dunglas.fr Tél. : 06 60 91 20 20
Re: [PHP-DEV] Internationalized Domain Name support in FILTER_VALIDATE_URL
On 22 Sep 2014, at 08:18, Kévin Dunglas dung...@gmail.com wrote: I'll implement optional (and not default) support of IDN in filter_var(). Does anyone known if it's better to use libIDN (LGPL) or ICU (custom license deviated from the X license) from a license point of view? We already use ICU in many places, so it's more likely to be available and people can get IDN support for free. I suppose, then, the license isn't an issue. -- Andrea Faulds http://ajf.me/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Loop... or...
Hey:
On Sat, Sep 20, 2014 at 5:56 AM, Leigh lei...@gmail.com wrote:
Hello list!
This is an item that has been repeatedly requested in various forms,
with no solid implementation to back it up, yet remaining quite
desirable to the developer community at large.
Loops with a default block, executed in the event that the loop is
never entered.
https://wiki.php.net/rfc/loop_or
Traditionally this is requested as a loop {} else {} structure,
however due to the choice of keyword this causes significant BC
problems.
I have written an RFC presenting this feature as loop {} or {} along
with how I intend to implement it. I have consulted with several core
contributors as well as normal developers, and this seems to be the
most BC-complete option.
A poll of local developers indicates a strong positive response
supporting this feature, so please take the time to consider and
discuss what is laid out in the RFC, as many of us would like this to
become a permanent fixture of the language.
I especially need input regarding Opcache concerns, as this is not an
area of expertise for me.
I will be developing the patch myself, and hope to have a full proof
of concept completed by the end of this weekend. (for and while are
both working, foreach currently segfaults, I am working on it)
Thanks for reading.
Leigh.
Maybe I am too conservative. I don't like this idea. :
And I DO THINK, we should try to stop brings lots of new things into PHP7.
I am worring whether it can be release in the next year
thanks
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
--
Xinchen Hui
@Laruence
http://www.laruence.com/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Internationalized Domain Name support in FILTER_VALIDATE_URL
On 22/09/14 08:47, Andrea Faulds wrote: Does anyone known if it's better to use libIDN (LGPL) or ICU (custom license deviated from the X license) from a license point of view? We already use ICU in many places, so it's more likely to be available and people can get IDN support for free. I suppose, then, the license isn't an issue. Has any alternative to ICU been found yet as a base for unicode support in PHP7 in general? -- 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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Change checkdnsrr() $type argument behavior
On Mon, Sep 22, 2014 at 9:07 AM, Kris Craig kris.cr...@gmail.com wrote: On Sep 21, 2014 11:52 PM, Pierre Joye pierre@gmail.com wrote: Well, for what I can see users already take into account this part of the issue then: https://github.com/search?l=phpq=checkdnsrrtype=Codeutf8=%E2%9C%93 changing the default will make create code compatibility between 5.x and 7.x, killing the gains we may have by changing the default. Cheers, -- Pierre @pierrejoye | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Change checkdnsrr() $type argument behavior
On Sep 22, 2014 1:09 AM, Pierre Joye pierre@gmail.com wrote: On Mon, Sep 22, 2014 at 9:07 AM, Kris Craig kris.cr...@gmail.com wrote: On Sep 21, 2014 11:52 PM, Pierre Joye pierre@gmail.com wrote: Well, for what I can see users already take into account this part of the issue then: https://github.com/search?l=phpq=checkdnsrrtype=Codeutf8=%E2%9C%93 changing the default will make create code compatibility between 5.x and 7.x, killing the gains we may have by changing the default. Cheers, -- Pierre @pierrejoye | http://www.libgd.org That's why we have the option of just making that arg required without a default, which would be targetted for PHP 7. --Kris
Re: [PHP-DEV] [VOTE][RFC] Integer Semantics
On Monday, 22 September 2014, Andrea Faulds a...@ajf.me wrote: On 21 Sep 2014, at 22:49, Peter Cowburn petercowb...@gmail.com javascript:; wrote: It is closed now. The vote is closed now, fact. That does not prevent further (hopefully productive) discussion from happening, and it also doesn’t stipulate that the RFC must be merged. The RFC is merged. I suppose you could revert the changes, though it’d be a significant hassle. Immediately reverting a change is a knee-jerk reaction that should not take place. That said, this vote was closed early, whether deliberately or not, and merged, which goes against everything we've been aiming for with the RFC process. Closing the vote at the most convenient opportunity, when it suits the author most, is not cool. I didn’t close it because the time suited me most. I made an honest mistake and closed it 22 or so hours early because I forgot I’d opened the vote at ~23:00 and not ~02:00. Unfortunately, I realised my mistake after merging the patch. This was definitely not intentional. If you say so. Still, the asking of individuals to remove their votes so that the tally is in you favour is inexcusable. -- Andrea Faulds http://ajf.me/
Re: [PHP-DEV] [RFC] Loop... or...
On 22 September 2014 08:17, Christian Stoller stol...@leonex.de wrote: I like this proposal as I am using this feature in Twig very often. But I would really prefer using else instead of or, because it is already common in the mentioned projects. Maybe you could reconsider if it is really not possible to use else. It's _really_ not possible to use else without a huge BC break in one form or another, something I'm trying to avoid at all costs. What about making the brackets for the loop block obligatory for using this feature? Unfortunately that wouldn't help, we'd have to enforce braces on everything (if/else/elseif/while/for/etc) to make it possible to hang an else on the bottom of a loop, again a pretty big BC break. I have actually discussed braces everywhere with several internals devs, and the response has been pretty much unanimous: We'd like it, but it will never pass the vote. It would be trivial to provide a migration script though. Feel free to test the water with this idea ;) -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Change checkdnsrr() $type argument behavior
On Mon, Sep 22, 2014 at 10:56 AM, Kris Craig kris.cr...@gmail.com wrote: On Sep 22, 2014 1:09 AM, Pierre Joye pierre@gmail.com wrote: On Mon, Sep 22, 2014 at 9:07 AM, Kris Craig kris.cr...@gmail.com wrote: On Sep 21, 2014 11:52 PM, Pierre Joye pierre@gmail.com wrote: Well, for what I can see users already take into account this part of the issue then: https://github.com/search?l=phpq=checkdnsrrtype=Codeutf8=%E2%9C%93 changing the default will make create code compatibility between 5.x and 7.x, killing the gains we may have by changing the default. Cheers, -- Pierre @pierrejoye | http://www.libgd.org That's why we have the option of just making that arg required without a default, which would be targetted for PHP 7. I got that :) but now imagine one doing the following call now: checkdnsrr(myhost) == TRUE where only MX was set and we suddenly change the default to ANY but ANY does not include MX, then the validation will simply fail and the code will become either: checkdnsrr(myhost, 'MX') == TRUE and for what I see, most of the usages are done to valid emails. I am not saying I am against such changes, I only do not see the gains but the possible pains in a couple of situations, these pains will make migration harder with no technical gains from our side. Cheers, -- Pierre @pierrejoye | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE][RFC] Integer Semantics
On Mon, Sep 22, 2014 at 11:02 AM, Peter Cowburn petercowb...@gmail.com wrote: If you say so. Still, the asking of individuals to remove their votes so that the tally is in you favour is inexcusable. did I miss something? What is this request to remove votes thing? -- Pierre @pierrejoye | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Loop... or...
On 22 September 2014 08:49, Xinchen Hui larue...@php.net wrote: Maybe I am too conservative. I don't like this idea. : And I DO THINK, we should try to stop brings lots of new things into PHP7. I am worring whether it can be release in the next year Can you give some more details on why you don't like the idea? Is there anything I can do to the proposal to make it more acceptable? I don't think you should worry this postponing the release. I plan to do all of the work for this, it shouldn't cost you any time at all except a few lines about your opinion. I'm not comfortable deep diving into the core, so it's not like I can help make the release go faster if I stop work on this. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE][RFC] Integer Semantics
On 22 September 2014 10:21, Pierre Joye pierre@gmail.com wrote: On Mon, Sep 22, 2014 at 11:02 AM, Peter Cowburn petercowb...@gmail.com wrote: If you say so. Still, the asking of individuals to remove their votes so that the tally is in you favour is inexcusable. did I miss something? What is this request to remove votes thing? Pierre, it didn’t take place on-list. [1] [2] [3] [4] [5] In summary, Andrea asked individuals, myself included, several times to remove their “no” votes purely to cross the 2/3 majority threshold. That, along with their timely concerns raised both on- and off-list about who can vote, leads me to think… “shenanigans”. [6] What’s done is done, the RFC passed and was merged… let’s move along to getting stuff done. -- Pierre @pierrejoye | http://www.libgd.org [1] http://chat.stackoverflow.com/transcript/11?m=18895597#18895597 [2] http://chat.stackoverflow.com/transcript/11?m=18948500#18948500 [3] http://chat.stackoverflow.com/transcript/11?m=18986456#18986456 [4] http://chat.stackoverflow.com/transcript/11?m=18986542#18986542 [5] http://chat.stackoverflow.com/transcript/11?m=19003711#19003711 [6] http://dictionary.reference.com/browse/shenanigans
Re: [PHP-DEV] [VOTE][RFC] Integer Semantics
WTF is going on here? Looks like the vote was closed nearly 24 hours early on a weekend. While the latter is not nice, closing early is a no-go. So what are we going to do? Reopen the vote for another day or completely restart it? -- Regards, Mike -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE][RFC] Integer Semantics
On Mon, Sep 22, 2014 at 11:36 AM, Michael Wallner m...@php.net wrote: WTF is going on here? Looks like the vote was closed nearly 24 hours early on a weekend. While the latter is not nice, closing early is a no-go. So what are we going to do? Reopen the vote for another day or completely restart it? This is getting really annoying. 2nd or 3rd time it happens, between people changing contents during votes, closing too early, too late, asking to change votes, etc. As we can't fix the lobbying part of it we can fix the time, content and periods issue. I will drop a mail later today to propose a solution, avoiding this. -- Pierre @pierrejoye | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE][RFC] Integer Semantics
On Mon, Sep 22, 2014 at 5:35 PM, Peter Cowburn petercowb...@gmail.com wrote: On 22 September 2014 10:21, Pierre Joye pierre@gmail.com wrote: On Mon, Sep 22, 2014 at 11:02 AM, Peter Cowburn petercowb...@gmail.com wrote: If you say so. Still, the asking of individuals to remove their votes so that the tally is in you favour is inexcusable. did I miss something? What is this request to remove votes thing? Pierre, it didn’t take place on-list. [1] [2] [3] [4] [5] In summary, Andrea asked individuals, myself included, several times to remove their “no” votes purely to cross the 2/3 majority threshold. That, along with their timely concerns raised both on- and off-list about who can vote, leads me to think… “shenanigans”. [6] ask people to vote yes, close the vote immeditely once it reach the 2/3 requirement.. it's not cool, and it's not about RFC process... it's about manner... thanks What’s done is done, the RFC passed and was merged… let’s move along to getting stuff done. -- Pierre @pierrejoye | http://www.libgd.org [1] http://chat.stackoverflow.com/transcript/11?m=18895597#18895597 [2] http://chat.stackoverflow.com/transcript/11?m=18948500#18948500 [3] http://chat.stackoverflow.com/transcript/11?m=18986456#18986456 [4] http://chat.stackoverflow.com/transcript/11?m=18986542#18986542 [5] http://chat.stackoverflow.com/transcript/11?m=19003711#19003711 [6] http://dictionary.reference.com/browse/shenanigans -- Xinchen Hui @Laruence http://www.laruence.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE][RFC] Integer Semantics
On 22 Sep 2014, at 10:46, Xinchen Hui larue...@php.net wrote: ask people to vote yes, close the vote immeditely once it reach the 2/3 requirement.. it's not cool, and it's not about RFC process... it's about manner… I didn’t close it because it reached the 2/3 requirement. I was lucky that one more person voted before I closed it. I made an honest mistake and closed it too early. -- Andrea Faulds http://ajf.me/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE][RFC] Integer Semantics
On 22/09/14 10:42, Pierre Joye wrote: This is getting really annoying. 2nd or 3rd time it happens, between people changing contents during votes, closing too early, too late, asking to change votes, etc. At a very least a vote should not end until at least 7 days after the last change to the RFC being voted on? But 7 days STILL seems too short when like yourself Pierre, people can be out on the road for a week? -- 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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Change checkdnsrr() $type argument behavior
On Sep 22, 2014 2:16 AM, Pierre Joye pierre@gmail.com wrote: On Mon, Sep 22, 2014 at 10:56 AM, Kris Craig kris.cr...@gmail.com wrote: On Sep 22, 2014 1:09 AM, Pierre Joye pierre@gmail.com wrote: On Mon, Sep 22, 2014 at 9:07 AM, Kris Craig kris.cr...@gmail.com wrote: On Sep 21, 2014 11:52 PM, Pierre Joye pierre@gmail.com wrote: Well, for what I can see users already take into account this part of the issue then: https://github.com/search?l=phpq=checkdnsrrtype=Codeutf8=%E2%9C%93 changing the default will make create code compatibility between 5.x and 7.x, killing the gains we may have by changing the default. Cheers, -- Pierre @pierrejoye | http://www.libgd.org That's why we have the option of just making that arg required without a default, which would be targetted for PHP 7. I got that :) but now imagine one doing the following call now: checkdnsrr(myhost) == TRUE where only MX was set and we suddenly change the default to ANY but ANY does not include MX, then the validation will simply fail and the code will become either: Why doesn't ANY include MX? That also seems counter-intuitive, as one would assume that ANY would check for any type of record. checkdnsrr(myhost, 'MX') == TRUE and for what I see, most of the usages are done to valid emails. Hmm that hasn't been my experience, but regardless, they should be using checkmxrr() for that, anyway. As it stands now, the default behavior of checkdnsrr() just redundantly mirrors the behavior of another function and for no apparent reason. I am not saying I am against such changes, I only do not see the gains but the possible pains in a couple of situations, these pains will make migration harder with no technical gains from our side. I do think it would be a usability gain, if not a technical one. And I've long been of the opinion that major version increments like PHP 7 are the ideal time to implement such improvements, even despite some potential edge-case BC. What if we got rid of the option to change the default and instead just went with making both args required? --Kris Cheers, -- Pierre @pierrejoye | http://www.libgd.org
Re: [PHP-DEV] [VOTE][RFC] Integer Semantics
On 22 Sep 2014, at 10:36, Michael Wallner m...@php.net wrote: WTF is going on here? Looks like the vote was closed nearly 24 hours early on a weekend. While the latter is not nice, closing early is a no-go. So what are we going to do? Reopen the vote for another day or completely restart it? If we’re going to reopen or restart, I’d prefer to completely restart it than to just reopen it. A clean slate. -- Andrea Faulds http://ajf.me/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Loop... or...
On 2014-09-21 02:21, Sara Golemon wrote:
On Sat, Sep 20, 2014 at 3:03 PM, Leigh lei...@gmail.com wrote:
On 20 September 2014 20:47, Sara Golemon p...@golemon.com wrote:
I like the general idea, but rather than explicitly focusing on
the 'or' keyword, how about just giving all loop constructs
(do/while/for/foreach) a return value? I'd suggest an integer
return value indicating the number of times the loop executed.
mind === blown
This would open up a huge amount of other functionality I'd never
dreamed of (some of which is quite scary!)
for($i = for(...) {}; $i ...) {}
Yikes, I truly hope nobody ever writes that code. Ever.
I'm really not sure I understand the full implication of this
though. This would mean changing loop constructs from statements
to expressions. I wonder how difficult that will actually be, and
what other problems it would cause (I obviously haven't played with
this idea yet).
I admit, I haven't thought it through entirely either. Nor even if
it's definitely possible.
It would also mean having to make { default block } into an
expression... with a return value (to be allowed on either side of
the boolean or)
Excellent point, a block only works with T_OR if it has a value.
I'm pretty sure that at this point, it doesn't. That does put a
monkey wrench into it. Perhaps a lambda could accommodate that?
Starts to get ugly though...
Lots to think about here, if it's at all viable this will need
it's own separate RFC, it's a much more invasive change, but
definitely a great idea.
Yeah, I might be trying too hard. Worth exploring a tiny bit
though...
-Sara
Actually, I once or twice wanted to use while() {} else {} instead of
wrapping the loop in an if. The extended version of Sara, while
looking great at a first glance, quickly turns into a crazy nightmare
after looking at the points already cooked up :)
--
Regards,
Mike
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE][RFC] Integer Semantics
On 22 September 2014 11:10, Andrea Faulds a...@ajf.me wrote: If we’re going to reopen or restart, I’d prefer to completely restart it than to just reopen it. A clean slate. Most of the issues I saw raised were related to one half of the RFC, the shifts or the casts, perhaps you'd make better headway splitting it in two. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Change checkdnsrr() $type argument behavior
On Mon, Sep 22, 2014 at 11:56 AM, Kris Craig kris.cr...@gmail.com wrote: On Sep 22, 2014 2:16 AM, Pierre Joye pierre@gmail.com wrote: On Mon, Sep 22, 2014 at 10:56 AM, Kris Craig kris.cr...@gmail.com wrote: On Sep 22, 2014 1:09 AM, Pierre Joye pierre@gmail.com wrote: On Mon, Sep 22, 2014 at 9:07 AM, Kris Craig kris.cr...@gmail.com wrote: On Sep 21, 2014 11:52 PM, Pierre Joye pierre@gmail.com wrote: Well, for what I can see users already take into account this part of the issue then: https://github.com/search?l=phpq=checkdnsrrtype=Codeutf8=%E2%9C%93 changing the default will make create code compatibility between 5.x and 7.x, killing the gains we may have by changing the default. Cheers, -- Pierre @pierrejoye | http://www.libgd.org That's why we have the option of just making that arg required without a default, which would be targetted for PHP 7. I got that :) but now imagine one doing the following call now: checkdnsrr(myhost) == TRUE where only MX was set and we suddenly change the default to ANY but ANY does not include MX, then the validation will simply fail and the code will become either: Why doesn't ANY include MX? That also seems counter-intuitive, as one would assume that ANY would check for any type of record. I meant in the case when a DNS record has no MX entry. checkdnsrr(myhost, 'MX') == TRUE and for what I see, most of the usages are done to valid emails. Hmm that hasn't been my experience, but regardless, they should be using checkmxrr() for that, anyway. As it stands now, the default behavior of checkdnsrr() just redundantly mirrors the behavior of another function and for no apparent reason. Other are only aliases, not the other way round. I am not saying I am against such changes, I only do not see the gains but the possible pains in a couple of situations, these pains will make migration harder with no technical gains from our side. I do think it would be a usability gain, if not a technical one. And I've long been of the opinion that major version increments like PHP 7 are the ideal time to implement such improvements, even despite some potential edge-case BC. What if we got rid of the option to change the default and instead just went with making both args required? Same results -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE][RFC] Integer Semantics
On Mon, 22 Sep 2014, Peter Cowburn wrote: On 22 September 2014 10:21, Pierre Joye pierre@gmail.com wrote: On Mon, Sep 22, 2014 at 11:02 AM, Peter Cowburn petercowb...@gmail.com wrote: If you say so. Still, the asking of individuals to remove their votes so that the tally is in you favour is inexcusable. did I miss something? What is this request to remove votes thing? Pierre, it didn’t take place on-list. [1] [2] [3] [4] [5] In summary, Andrea asked individuals, myself included, several times to remove their “no” votes purely to cross the 2/3 majority threshold. I would also like to point out that, just like a 8:8 vote is not a 50% majority, 16:8 is technically also not a two thirds *majority*. The RFC, like with many other important things is of course too vague on this. cheers, Derick -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] ext/date arguments handling
Hi Florian, On Sun, 21 Sep 2014, Florian Margaine wrote: I specifically mean to ask @derick about this issue I'm having, since he is the maintainer of ext/date. I wrote this pull request for the DateTimeZone::getOffset method to accept a DateTimeInterface instead of a DateTime object: https://github.com/php/php-src/pull/831 Instead of using ZEND_ARG_INFO, I use ZEND_ARG_OBJ_INFO rather than relying on zpp only. It makes the code consistent with the type hinting errors that should arise, and also gives a correct reflection. However, the rest of the code in this extension uses ZEND_ARG_INFO, only throwing warnings when the arguments are not of the right kind. Should I use ZEND_ARG_INFO and rely on zpp's warning, or should I use ZEND_ARG_OBJ_INFO, and eventually translate the other methods to use it too? This'd be out of this PR of course, but it makes sense to streamline the methods of ext/date. I think it should use ZEND_ARG_OBJ_INFO. However, I am not sure whether we can do that in 5.x because of BC reasons. It's these tiny mistakes that are the larger BC problems. So I would suggest that you make a PR for 5.6 without ZEND_ARG_OBJ_INFO, and one for 7 with ZEND_ARG_OBJ_INFO. I think the patch looks mostly good too. I would recommend you squash the commits into a single commit though. cheers, Derick -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE][RFC] Null Coalesce Operator
On Sat, 20 Sep 2014, Patrick Schaaf wrote: Am 20.09.2014 01:35 schrieb Andrea Faulds a...@ajf.me: https://wiki.php.net/rfc/isset_ternary#vote Hi, got a question after being bitten my the issue yesterday in the context of the @yadda ?: 'default' form yesterday: What about yadda that results, at the moment, in fatal errors?? Things like static::$missingproperty, $this-missingmethod(), and other stuff? Will the ?? operator A) make these non-fatal B) silently fatal (like now when @ is used) It should be this one to be consistent. @ is shit, but sadly can not be avoided in all situations. cheers, Derick -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Is it fair that people with no karma can vote on RFCs?
On Sat, 20 Sep 2014, Andrea Faulds wrote: Perhaps I’m being unfair and overthinking things, but I wonder if it is really fair for people who have no karma, i.e. not contributors to the documentation, extensions, php-src or anything else, to have the ability to vote on RFCs? I’d never suggest people without internals karma can’t vote. I think doc and peck contributors are as valued as any other contributors. However, people with no karma whatsoever (a blank people.php.net page) voting irks me. I think people's votes should only count if they have karma to the section of the code that the RFC/feature/whatever relates to. cheers, Derick -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Is it fair that people with no karma can vote on RFCs?
On Sat, 20 Sep 2014, Johannes Schlüter wrote: On Sat, 2014-09-20 at 03:16 +0100, Leigh wrote: I think everyone with the ability to vote should have to communicate their reasons behind their yes/no publicly on this mailing list for it to be valid. If you cannot describe in your own words why a proposal should or should not be accepted, why should your opinion be valid? That's one of the reasons why I consider voting as default way wrong. It might be a way to solve ties if a consensus can't be reached. That's another good point, that I stand behind. I think f.e. the integer semantics RFC was contentious enough to warrant further discussion and see what could make other people to say yes as well. The current RFC process does not state anything about reflecting comments on the ML to have to be addressed before the RFC can even be put to vote. And I think, valid (technical) objects should be required to be addressed. It is unclear what a no means. Might be a related to the patch the design, a misunderstanding or due to a critical issue ... in the end a vote creates losers with little feedback. But well, I'm saying this from day one of the voting. Yes. I am in that camp too. cheers, Derick -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] ext/date arguments handling
Hi Derick, Thanks for your answer! Indeed, I did plan on doing another PR for 5.6 while keeping ZEND_ARG_INFO. I'll review your notes and take care of them. Regards, *Florian Margaine* On Mon, Sep 22, 2014 at 1:29 PM, Derick Rethans der...@php.net wrote: Hi Florian, On Sun, 21 Sep 2014, Florian Margaine wrote: I specifically mean to ask @derick about this issue I'm having, since he is the maintainer of ext/date. I wrote this pull request for the DateTimeZone::getOffset method to accept a DateTimeInterface instead of a DateTime object: https://github.com/php/php-src/pull/831 Instead of using ZEND_ARG_INFO, I use ZEND_ARG_OBJ_INFO rather than relying on zpp only. It makes the code consistent with the type hinting errors that should arise, and also gives a correct reflection. However, the rest of the code in this extension uses ZEND_ARG_INFO, only throwing warnings when the arguments are not of the right kind. Should I use ZEND_ARG_INFO and rely on zpp's warning, or should I use ZEND_ARG_OBJ_INFO, and eventually translate the other methods to use it too? This'd be out of this PR of course, but it makes sense to streamline the methods of ext/date. I think it should use ZEND_ARG_OBJ_INFO. However, I am not sure whether we can do that in 5.x because of BC reasons. It's these tiny mistakes that are the larger BC problems. So I would suggest that you make a PR for 5.6 without ZEND_ARG_OBJ_INFO, and one for 7 with ZEND_ARG_OBJ_INFO. I think the patch looks mostly good too. I would recommend you squash the commits into a single commit though. cheers, Derick
Re: [PHP-DEV] [VOTE][RFC] Integer Semantics
On 22 Sep 2014, at 12:06, Derick Rethans der...@php.net wrote: I would also like to point out that, just like a 8:8 vote is not a 50% majority, 16:8 is technically also not a two thirds *majority*. The RFC, like with many other important things is of course too vague on this. An 8:8 vote is not a majority, no, but a 9:8 would be a 50%+1 majority. A 16:8 vote *is* a 2/3 majority. 2/3 of people have voted in favour, with 1/3 against. It’s a very narrow one, but so far I’m yet to see anyone say it should be 2/3+1 and not plain 2/3. -- Andrea Faulds http://ajf.me/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Is it fair that people with no karma can vote on RFCs?
On 22 Sep 2014, at 12:32, Derick Rethans der...@php.net wrote: On Sat, 20 Sep 2014, Andrea Faulds wrote: Perhaps I’m being unfair and overthinking things, but I wonder if it is really fair for people who have no karma, i.e. not contributors to the documentation, extensions, php-src or anything else, to have the ability to vote on RFCs? I’d never suggest people without internals karma can’t vote. I think doc and peck contributors are as valued as any other contributors. However, people with no karma whatsoever (a blank people.php.net page) voting irks me. I think people's votes should only count if they have karma to the section of the code that the RFC/feature/whatever relates to. Is that really fair? If we break BC, plenty of userland developers might be affected and they should have a right to chime in. -- Andrea Faulds http://ajf.me/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Is it fair that people with no karma can vote on RFCs?
On Mon, Sep 22, 2014 at 3:10 PM, Andrea Faulds a...@ajf.me wrote: On 22 Sep 2014, at 12:32, Derick Rethans der...@php.net wrote: On Sat, 20 Sep 2014, Andrea Faulds wrote: Perhaps I’m being unfair and overthinking things, but I wonder if it is really fair for people who have no karma, i.e. not contributors to the documentation, extensions, php-src or anything else, to have the ability to vote on RFCs? I’d never suggest people without internals karma can’t vote. I think doc and peck contributors are as valued as any other contributors. However, people with no karma whatsoever (a blank people.php.net page) voting irks me. I think people's votes should only count if they have karma to the section of the code that the RFC/feature/whatever relates to. Is that really fair? If we break BC, plenty of userland developers might be affected and they should have a right to chime in. That would be quite unfair, not just because of BC breaks and/or userland developers' votes (there aren't many, afaik). Practically every language change would be decided by only a handful of people, while it should be important that many votes are gathered for important decisions. Cheers, Andrey. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE][RFC] Integer Semantics
On 2014-09-22 14:08, Andrea Faulds wrote: On 22 Sep 2014, at 12:06, Derick Rethans der...@php.net wrote: I would also like to point out that, just like a 8:8 vote is not a 50% majority, 16:8 is technically also not a two thirds *majority*. The RFC, like with many other important things is of course too vague on this. The +1 is only for 50% majorities. An 8:8 vote is not a majority, no, but a 9:8 would be a 50%+1 majority. A 16:8 vote *is* a 2/3 majority. Yes, I think so, too. -- Regards, Mike -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Is it fair that people with no karma can vote on RFCs?
On Mon, 22 Sep 2014, Andrea Faulds wrote: On 22 Sep 2014, at 12:32, Derick Rethans der...@php.net wrote: On Sat, 20 Sep 2014, Andrea Faulds wrote: Perhaps I’m being unfair and overthinking things, but I wonder if it is really fair for people who have no karma, i.e. not contributors to the documentation, extensions, php-src or anything else, to have the ability to vote on RFCs? I’d never suggest people without internals karma can’t vote. I think doc and peck contributors are as valued as any other contributors. However, people with no karma whatsoever (a blank people.php.net page) voting irks me. I think people's votes should only count if they have karma to the section of the code that the RFC/feature/whatever relates to. Is that really fair? If we break BC, plenty of userland developers might be affected and they should have a right to chime in. Breaking BC should never happen anyway. cheers, Derick -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Is it fair that people with no karma can vote on RFCs?
On Mon, 22 Sep 2014, Andrey Andreev wrote: On Mon, Sep 22, 2014 at 3:10 PM, Andrea Faulds a...@ajf.me wrote: On 22 Sep 2014, at 12:32, Derick Rethans der...@php.net wrote: On Sat, 20 Sep 2014, Andrea Faulds wrote: Perhaps I’m being unfair and overthinking things, but I wonder if it is really fair for people who have no karma, i.e. not contributors to the documentation, extensions, php-src or anything else, to have the ability to vote on RFCs? I’d never suggest people without internals karma can’t vote. I think doc and peck contributors are as valued as any other contributors. However, people with no karma whatsoever (a blank people.php.net page) voting irks me. I think people's votes should only count if they have karma to the section of the code that the RFC/feature/whatever relates to. Is that really fair? If we break BC, plenty of userland developers might be affected and they should have a right to chime in. That would be quite unfair, not just because of BC breaks and/or userland developers' votes (there aren't many, afaik). Practically every language change would be decided by only a handful of people, while it should be important that many votes are gathered for important decisions. There is a big difference between votes, and voices. Voices should definitely be listened too. Derick -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE][RFC] Integer Semantics
On Mon, 22 Sep 2014, Michael Wallner wrote: On 2014-09-22 14:08, Andrea Faulds wrote: On 22 Sep 2014, at 12:06, Derick Rethans der...@php.net wrote: I would also like to point out that, just like a 8:8 vote is not a 50% majority, 16:8 is technically also not a two thirds *majority*. The RFC, like with many other important things is of course too vague on this. The +1 is only for 50% majorities. An 8:8 vote is not a majority, no, but a 9:8 would be a 50%+1 majority. A 16:8 vote *is* a 2/3 majority. Yes, I think so, too. I disagree, but the main point was something else. The voting RFC should be more clear on this. I don't think it is now. It's a pretty vague RFC in the first place, and leaves way too much open for interpretation. cheers, Derick -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE][RFC] Integer Semantics
On Sep 22, 2014 3:31 PM, Derick Rethans der...@php.net wrote: On Mon, 22 Sep 2014, Michael Wallner wrote: On 2014-09-22 14:08, Andrea Faulds wrote: On 22 Sep 2014, at 12:06, Derick Rethans der...@php.net wrote: I would also like to point out that, just like a 8:8 vote is not a 50% majority, 16:8 is technically also not a two thirds *majority*. The RFC, like with many other important things is of course too vague on this. The +1 is only for 50% majorities. An 8:8 vote is not a majority, no, but a 9:8 would be a 50%+1 majority. A 16:8 vote *is* a 2/3 majority. Yes, I think so, too. I disagree, but the main point was something else. Right, but what would be 2/3 of 24 votes for you then? The voting RFC should be more clear on this. I don't think it is now. It's a pretty vague RFC in the first place, and leaves way too much open for interpretation. For? # of votes? cheers, Derick
Re: [PHP-DEV] Is it fair that people with no karma can vote on RFCs?
On Sep 22, 2014 3:29 PM, Derick Rethans der...@php.net wrote: On Mon, 22 Sep 2014, Andrey Andreev wrote: On Mon, Sep 22, 2014 at 3:10 PM, Andrea Faulds a...@ajf.me wrote: On 22 Sep 2014, at 12:32, Derick Rethans der...@php.net wrote: On Sat, 20 Sep 2014, Andrea Faulds wrote: Perhaps I’m being unfair and overthinking things, but I wonder if it is really fair for people who have no karma, i.e. not contributors to the documentation, extensions, php-src or anything else, to have the ability to vote on RFCs? I’d never suggest people without internals karma can’t vote. I think doc and peck contributors are as valued as any other contributors. However, people with no karma whatsoever (a blank people.php.net page) voting irks me. I think people's votes should only count if they have karma to the section of the code that the RFC/feature/whatever relates to. Is that really fair? If we break BC, plenty of userland developers might be affected and they should have a right to chime in. That would be quite unfair, not just because of BC breaks and/or userland developers' votes (there aren't many, afaik). Practically every language change would be decided by only a handful of people, while it should be important that many votes are gathered for important decisions. There is a big difference between votes, and voices. Voices should definitely be listened too. We agree on listening. Only not on how we listen. Derick -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Is it fair that people with no karma can vote on RFCs?
IMHO, denying non-karma people to vote is like to making PHP a company's product, or, in another words, you use what we built and shut up, because only listening people won't allow to accept/deny a particular RFC, only votes do. People surely don't comment (myself included) why they are choosing some particular option on a RFC, but they are making their opinion count, and I think this kind of democracy power shouldn't be voided. Using separated voting count isn't an option? Like only internal changes are voted only by people with karma and features/changes/small BC breaks that affects userland are allowed to anyone. This way I believe is easy to say if either internals and community agrees with the proposed change and community people are making their opinion count. On Mon, Sep 22, 2014 at 10:39 AM, Pierre Joye pierre@gmail.com wrote: On Sep 22, 2014 3:29 PM, Derick Rethans der...@php.net wrote: On Mon, 22 Sep 2014, Andrey Andreev wrote: On Mon, Sep 22, 2014 at 3:10 PM, Andrea Faulds a...@ajf.me wrote: On 22 Sep 2014, at 12:32, Derick Rethans der...@php.net wrote: On Sat, 20 Sep 2014, Andrea Faulds wrote: Perhaps I’m being unfair and overthinking things, but I wonder if it is really fair for people who have no karma, i.e. not contributors to the documentation, extensions, php-src or anything else, to have the ability to vote on RFCs? I’d never suggest people without internals karma can’t vote. I think doc and peck contributors are as valued as any other contributors. However, people with no karma whatsoever (a blank people.php.net page) voting irks me. I think people's votes should only count if they have karma to the section of the code that the RFC/feature/whatever relates to. Is that really fair? If we break BC, plenty of userland developers might be affected and they should have a right to chime in. That would be quite unfair, not just because of BC breaks and/or userland developers' votes (there aren't many, afaik). Practically every language change would be decided by only a handful of people, while it should be important that many votes are gathered for important decisions. There is a big difference between votes, and voices. Voices should definitely be listened too. We agree on listening. Only not on how we listen. Derick -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: OpenSSL bug in 5.4.33 and 5.5.17
On Fri, Sep 19, 2014 at 6:49 PM, Remi Collet r...@fedoraproject.org wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Le 19/09/2014 18:25, Daniel Lowrey a écrit : In an effort to fix a very old (seven years old) DoS vulnerability involving encrypted streams I created a regression where feof() notifications on encrypted sockets are broken. This is present in both the most recent 5.4.33 and 5.5.17 releases. Can you please point us to the related commit... (which one cause the regression, which ones are useful) In 5.4.33 and 5.5.17 an immediate fix is to revert these commits: http://git.php.net/?p=php-src.git;a=commitdiff;h=6569db88081562f68a4f79e52cba83482bdf05fc http://git.php.net/?p=php-src.git;a=commitdiff;h=372844918a318ad712e16f9ec636682424a65403 http://git.php.net/?p=php-src.git;a=commitdiff;h=32be79dcfa1bc5af8682d9f512da68c5b3e2cbf3 The last of these (32be79d) has already been fixed upstream by f86b2193a483f56b0bd056570a0cdb57ebe66e2f but this change did not go into 5.4.33 and 5.5.17. Any reverts should also consider f86b2193. Does a revert of the first enough to get back to previous behavior? Yes, reverting the above commits above will fix any issues. I'm awaiting word from someone associated with Horde to verify that the previously linked patch ( https://bugs.php.net/patch-display.php?bug=41631patch=bug41631.patchrevision=1411139621) resolves the issue. As long as that works as expected I can merge that and everything should be resolved going forward. After a quick check 6569db8 and 32be79d are in 5.4.33 / 5.5.17 / 5.6.1RC1 f86b219 and 3728449 are in 5.6.1RC1 only -BEGIN PGP SIGNATURE- Version: GnuPG v2 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlQcXrUACgkQYUppBSnxahgfigCfUYmoYXJJYC0JKmLi/tg+mo1r mwwAoNXbDpPsdrVfzFWUy4tuOssqR256 =OUHp -END PGP SIGNATURE- -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php Hi, That's a bad thing we need to fix ASAP. I think for 5.6.1 we'll revert it , if not, we'll need an RC2, which is something we usually don't do (but as this could involve security, we may do it). The fix can be merged to 5.5.18RC1, next week, to have an RC cycle if not part of a 5.6.1RC2 (tag is tomorrow) 5.6 and 5.5 actually overlap in the release weeks. 5.6 is planned on odd weeks whereas 5.5 is on even weeks. Waiting for Ferenc's advice anyway. Julien.P -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Is it fair that people with no karma can vote on RFCs?
On September 22, 2014 4:21:29 PM CEST, Rafael Kassner kass...@php.net wrote: IMHO, denying non-karma people to vote is like to making PHP a company's product, or, in another words, you use what we built and shut up, because only listening people won't allow to accept/deny a particular RFC, only votes do. People surely don't comment (myself included) why they are choosing some particular option on a RFC, but they are making their opinion count, and I think this kind of democracy power shouldn't be voided. Slightly provocative: Why should I be forced to maintain code by people who don't want to maintain it themselves? Probably even due to votes by people about whom I don't know anything? Mind that most maintenance work by most contributors happens in free time on a voluntarily base. And no open source doesn't mean democracy as governing model. The democratic part is that people who don't like it can fork the project and eventually receive a higher traction. But no, one man one vote and full equality doesn't work out. (i.e. if a modules primary maintainer vetos a change I have to mind that [which doesn't mean I have to agree in the end]) Using separated voting count isn't an option? Like only internal changes are voted only by people with karma and features/changes/small BC breaks that affects userland are allowed to anyone. This way I believe is easy to say if either internals and community agrees with the proposed change and community people are making their opinion count. There are no plans (and enough people who'd veto such plans) to close the mailing list. Everybody might state their opinion and we are happy to receive (constructive) feedback and ideas here. And yes, this can be a bit painful due to different forms of trolling but leads to better results respecting more opinions than a yes/no vote. johannes -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] PHP 5.6 and default cipher list in OpenSSL
Hi, Sorry to have not detect this problem at RFC time, but the new hardcoded cipher list, cause some trouble in Fedora. See: https://bugs.php.net/68074 http://fedoraproject.org/wiki/Changes/CryptoPolicy https://fedoraproject.org/wiki/User:Nmav/CryptoPolicies https://wiki.php.net/rfc/improved-tls-defaults#default_ciphers And the simple patch https://bugs.php.net/patch-display.php?bug_id=68074patch=system-ciphers.patchrevision=latest If no objection, plan to apply this quite soon in 5.6+ Cheers, Remi. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] PHP 5.6 and default cipher list in OpenSSL
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, Sorry to have not detect this problem at RFC time, but the new hardcoded cipher list, cause some trouble in Fedora. See: https://bugs.php.net/68074 http://fedoraproject.org/wiki/Changes/CryptoPolicy https://fedoraproject.org/wiki/User:Nmav/CryptoPolicies https://wiki.php.net/rfc/improved-tls-defaults#default_ciphers And the simple patch https://bugs.php.net/patch-display.php?bug_id=68074patch=system-ciphers.patchrevision=latest If no objection, plan to apply this quite soon in 5.6+ Cheers, Remi. -BEGIN PGP SIGNATURE- Version: GnuPG v2 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlQgR04ACgkQYUppBSnxahhXvQCgwtPYInzckq6ZoWunPK8hL2UY Qd4AoNa7v50CBnLWcBRfhC9Zsl53/DVK =nV+z -END PGP SIGNATURE- -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: PHP 5.6 and default cipher list in OpenSSL
Hi, Sorry to have not detect this problem at RFC time, but the new hardcoded cipher list, cause some trouble in Fedora. See: https://bugs.php.net/68074 http://fedoraproject.org/wiki/Changes/CryptoPolicy https://fedoraproject.org/wiki/User:Nmav/CryptoPolicies https://wiki.php.net/rfc/improved-tls-defaults#default_ciphers And the simple patch https://bugs.php.net/patch-display.php?bug_id=68074patch=system-ciphers.patchrevision=latest If no objection, plan to apply this quite soon in 5.6+ This is sensible to me. It gives distros the ability to fine-tune crypto ciphers in accordance with their own policies and legal requirements. This has been an issue for RHEL at least in the past with regard to elliptic curve ciphers. Adding the compile directive would protect users by default with the new ciphers without causing problems for those adhering to specific organization/institutional requirements.
Re: [PHP-DEV] Is it fair that people with no karma can vote on RFCs?
On Mon, Sep 22, 2014 at 5:38 PM, Johannes Schlüter johan...@schlueters.de wrote: Slightly provocative: Why should I be forced to maintain code by people who don't want to maintain it themselves? Probably even due to votes by people about whom I don't know anything? Mind that most maintenance work by most contributors happens in free time on a voluntarily base. The same applies to many new codes. Even more for my team as we have to take care of many issues where only a few actually takes care of. And no open source doesn't mean democracy as governing model. The democratic part is that people who don't like it can fork the project and eventually receive a higher traction. But no, one man one vote and full equality doesn't work out. (i.e. if a modules primary maintainer vetos a change I have to mind that [which doesn't mean I have to agree in the end]) Primary maintainers doing only maintenance but not having actually designed/implemented an extension fits in this description. That sounds pretty awkward to me, for anything landing in the core. Landed in the core? Dictartorship goes away. Using separated voting count isn't an option? Like only internal changes are voted only by people with karma and features/changes/small BC breaks that affects userland are allowed to anyone. This way I believe is easy to say if either internals and community agrees with the proposed change and community people are making their opinion count. There are no plans (and enough people who'd veto such plans) to close the mailing list. Everybody might state their opinion and we are happy to receive (constructive) feedback and ideas here. And yes, this can be a bit painful due to different forms of trolling but leads to better results respecting more opinions than a yes/no vote. Never worked before and it will suddenly work? I am open to know how one can make it works. Unless you mean to go back to individual deciding everything for a given area or ext. Cheers, -- Pierre @pierrejoye | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: Re: OpenSSL bug in 5.4.33 and 5.5.17
Hi, That's a bad thing we need to fix ASAP. I think for 5.6.1 we'll revert it , if not, we'll need an RC2, which is something we usually don't do (but as this could involve security, we may do it). The fix can be merged to 5.5.18RC1, next week, to have an RC cycle if not part of a 5.6.1RC2 (tag is tomorrow) 5.6 and 5.5 actually overlap in the release weeks. 5.6 is planned on odd weeks whereas 5.5 is on even weeks. Waiting for Ferenc's advice anyway. Julien.P I have no issues with reverting at this point as that's the best route to get stable releases back on track. I thought I had fixed some really old bugs with those commits but the medicine turned out to be worse than the disease. My apologies again for letting those problems sneak into releases :/
Re: [PHP-DEV] Is it fair that people with no karma can vote on RFCs?
On 9/20/14, 0:11 , Sara Golemon wrote: On Sep 19, 2014, at 18:29, Andrea Faulds a...@ajf.me wrote: Perhaps I’m being unfair and overthinking things, Yes, you are. but I wonder if it is really fair for people who have no karma, i.e. not contributors to the documentation, extensions, php-src or anything else, to have the ability to vote on RFCs? Yes, it is. -Sara Yes, What Sara said. I am the type of person that would be excluded. I contributed to PHP a lot 10 years ago. However, in all the SVN and GIT moving, all my karma has long since been removed. I vote in almost every RFC because I have a long history with PHP and care about where it is going. People with dead accounts and who don't care about PHP most likely don't vote. Brian Moon brianlm...@php.net -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] VCS Account Request: fmargaine
Hi, Having done a few PRs now, I\#039;d like to assign bugs to myself on bugs.php.net to avoid having several people working on the same one. For this, I need a php.net account :-) -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] The ABI and bug 68057
https://bugs.php.net/bug.php?id=68057 is a regression introduced in PHP 5.6. So code which still worked with PHP 5.5 breaks in 5.6. The big issue is here, that the fix for this bug requires ABI breakage. (changing an unsigned short into a zend_uint) I know that ABI compatibility is a pretty serious issue here, but it also means that some perfectly valid PHP 5.5 code which is supposed to still work on 5.6 will silently break. So, is it worth to break ABI or does it have to wait for 5.7 or the next major? Bob -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Is it fair that people with no karma can vote on RFCs?
-Original Message- From: Derick Rethans [mailto:der...@php.net] Sent: Monday, September 22, 2014 2:33 PM To: Andrea Faulds Cc: PHP internals Subject: Re: [PHP-DEV] Is it fair that people with no karma can vote on RFCs? I think people's votes should only count if they have karma to the section of the code that the RFC/feature/whatever relates to. I agree with that, to a degree. I think it depends on whether we're talking about implementation RFCs or feature RFCs. As I mentioned in the past, when the Voting RFC was written - I never envisioned it would be used for implementation decisions. Maybe it was short sighted, maybe not - but to me, it was obvious that implementation would be up to the respective code owners, and not the full voter base. So yes, implementation issues that deal with the engine should be decided by those who have engine karma. Implementation decisions to the mysqli extension should be up to those who contributed to this codebase, even if there's just a handful of them. And so on and so forth. Johannes recent comments about maintenance of code are a major reason behind this approach, but it goes beyond fairness. The contributors are the domain experts in the respective implementations - it makes no sense to open this up to the voter base at large. You want to have a say? By all means, work your way in and contribute; Once you do, you'd have a vote. Until then, you have a voice in internals, but not a vote. The second group is trickier - and those are language features and other types of votes. The way we work today - where SVN yes/no is the only question - was absolutely not the intent of the Voting RFC and thankfully, it's also clearly not the language it contains. The original RFC read the following: * People with php.net SVN accounts that have contributed code to PHP * Representatives from the PHP community, that will be chosen by those with php.net SVN accounts Unfortunately, this was changed without me noticing it at the time, to the following: * People with php.net SVN accounts that have contributed code to PHP * Representatives from the PHP community, that will be chosen by those with php.net SVN accounts * Lead developers of PHP based projects (frameworks, cms, tools, etc.) * regular participant of internals discussions The first bullet is the one this thread deals with so far. It clearly states that having an SVN account isn't enough - but that code contributions to PHP are mandatory. We should probably consider revising that to also account for people contributing docs and other types of submissions. I'd also consider adding a requirement for contributing at least X commits (say 20 or 50) so that someone who did a one-off or two-off patch won't have the same vote as someone who contributed hundreds or thousands of commits. I believe this data can be easily pulled from git. While we're at it, IMHO, the second bucket is open ended and must be much more well defined. I think we need a process where people from the community can be nominated and voted on - either by people from the first line, or by some sort of a public community poll. Having 'elections' for representatives from the community doesn't sound like a bad idea to me :) Another option is to take the 1-2 top contributors of the 10-20 top PHP projects on github. That's probably a lot easier and would eliminate much of the politics involved. Last, the 2nd sub-bullet of the 2nd bullet (regular participant of internals discussions) is especially problematic - as it basically pulls the barrier to entry to nothing, and is the opposite of well-defined. When we revise the Voting RFC, it should go IMHO. Talk is cheap - the way to get a vote with PHP is to contribute - be it with code, docs, testing, frameworks or apps. Zeev -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Is it fair that people with no karma can vote on RFCs?
On Sep 22, 2014 8:56 PM, Zeev Suraski z...@zend.com wrote: Last, the 2nd sub-bullet of the 2nd bullet (regular participant of internals discussions) is especially problematic - as it basically pulls the barrier to entry to nothing, and is the opposite of well-defined. When we revise the Voting RFC, it should go IMHO. Talk is cheap - the way to get a vote with PHP is to contribute - be it with code, docs, testing, frameworks or apps. To kill the FUD about totally random ppl being able to vote: To my knowdlege, nobody fitting in what is describe in this last line ever voted. If someone knows a case where it happened, let me know.
RE: [PHP-DEV] Is it fair that people with no karma can vote on RFCs?
On Sep 22, 2014 8:56 PM, Zeev Suraski z...@zend.com wrote: account for people contributing docs and other types of submissions. I'd also consider adding a requirement for contributing at least X commits (say 20 or 50) so that someone who did a one-off or two-off patch won't have the same vote as someone who contributed hundreds or thousands of commits. I believe this data can be easily pulled from git. And let add a time since actual last commit too? This is bad in so many ways...
Re: [PHP-DEV] The ABI and bug 68057
On Mon, Sep 22, 2014 at 8:48 PM, Bob Weinand bobw...@hotmail.com wrote: https://bugs.php.net/bug.php?id=68057 is a regression introduced in PHP 5.6. So code which still worked with PHP 5.5 breaks in 5.6. The big issue is here, that the fix for this bug requires ABI breakage. (changing an unsigned short into a zend_uint) I know that ABI compatibility is a pretty serious issue here, but it also means that some perfectly valid PHP 5.5 code which is supposed to still work on 5.6 will silently break. So, is it worth to break ABI or does it have to wait for 5.7 or the next major? Is the actual code used by the parser exposed? If yes it will be somehow bad as ext maintainers relying on this will need two different builds. I do not think there are many affected exts out there tho'. If not, then it is easy :) -- Pierre @pierrejoye | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE][RFC] Integer Semantics
On Sep 22, 2014 10:05 PM, Levi Morrison le...@php.net wrote: I don't want to say anything else here, as technically this is thread hijacking (sorry Andrea) but I am very interested in collaborating with anyone who would like to try to improve the RFC process. Perhaps reply to me off-list if you are also interested. This is already a bad start to make this process more open or clear.
Re: [PHP-DEV] [VOTE][RFC] Integer Semantics
Hi, Just a side remark: from an external point of view, it seems like you need an application to handle the RFCs. An application with a strict business logic, which leaves no ambiguity as to when and how an RFC should be valid. The what is more ambiguous however, and I'm not sure as to how it should be handled. Regards, *Florian Margaine* On Mon, Sep 22, 2014 at 10:05 PM, Levi Morrison le...@php.net wrote: On Mon, Sep 22, 2014 at 3:37 PM, Pierre Joye pierre@gmail.com wrote: On Sep 22, 2014 3:31 PM, Derick Rethans der...@php.net wrote: On Mon, 22 Sep 2014, Michael Wallner wrote: On 2014-09-22 14:08, Andrea Faulds wrote: On 22 Sep 2014, at 12:06, Derick Rethans der...@php.net wrote: I would also like to point out that, just like a 8:8 vote is not a 50% majority, 16:8 is technically also not a two thirds *majority*. The RFC, like with many other important things is of course too vague on this. The +1 is only for 50% majorities. An 8:8 vote is not a majority, no, but a 9:8 would be a 50%+1 majority. A 16:8 vote *is* a 2/3 majority. Yes, I think so, too. I disagree, but the main point was something else. Right, but what would be 2/3 of 24 votes for you then? The voting RFC should be more clear on this. I don't think it is now. It's a pretty vague RFC in the first place, and leaves way too much open for interpretation. For? # of votes? I have actually been working with several other people trying to come up with smarter rules for the way we work with RFCs. Undoubtably, confusion about what constitutes a language change is a huge issue. To be completely honest, I would prefer that we require 2/3 on all RFCs. PHP is a mature language; if we can't get 2/3 to agree on something it probably isn't good for the whole of the PHP project. I don't want to say anything else here, as technically this is thread hijacking (sorry Andrea) but I am very interested in collaborating with anyone who would like to try to improve the RFC process. Perhaps reply to me off-list if you are also interested.
Re: [PHP-DEV] [VOTE][RFC] Integer Semantics
On Mon, Sep 22, 2014 at 3:37 PM, Pierre Joye pierre@gmail.com wrote: On Sep 22, 2014 3:31 PM, Derick Rethans der...@php.net wrote: On Mon, 22 Sep 2014, Michael Wallner wrote: On 2014-09-22 14:08, Andrea Faulds wrote: On 22 Sep 2014, at 12:06, Derick Rethans der...@php.net wrote: I would also like to point out that, just like a 8:8 vote is not a 50% majority, 16:8 is technically also not a two thirds *majority*. The RFC, like with many other important things is of course too vague on this. The +1 is only for 50% majorities. An 8:8 vote is not a majority, no, but a 9:8 would be a 50%+1 majority. A 16:8 vote *is* a 2/3 majority. Yes, I think so, too. I disagree, but the main point was something else. Right, but what would be 2/3 of 24 votes for you then? The voting RFC should be more clear on this. I don't think it is now. It's a pretty vague RFC in the first place, and leaves way too much open for interpretation. For? # of votes? I have actually been working with several other people trying to come up with smarter rules for the way we work with RFCs. Undoubtably, confusion about what constitutes a language change is a huge issue. To be completely honest, I would prefer that we require 2/3 on all RFCs. PHP is a mature language; if we can't get 2/3 to agree on something it probably isn't good for the whole of the PHP project. I don't want to say anything else here, as technically this is thread hijacking (sorry Andrea) but I am very interested in collaborating with anyone who would like to try to improve the RFC process. Perhaps reply to me off-list if you are also interested.
Re: [PHP-DEV] [VOTE][RFC] Integer Semantics
On Mon, Sep 22, 2014 at 10:09 PM, Pierre Joye pierre@gmail.com wrote: On Sep 22, 2014 10:05 PM, Levi Morrison le...@php.net wrote: I don't want to say anything else here, as technically this is thread hijacking (sorry Andrea) but I am very interested in collaborating with anyone who would like to try to improve the RFC process. Perhaps reply to me off-list if you are also interested. This is already a bad start to make this process more open or clear. No, you simply failed to understand it. Collaboration in a smaller group first, then open it up later. This catches a significant number of issues before hitting the list, making the time on-list more valuable. I wish *every* RFC was conducted in this fashion.
Re: [PHP-DEV] [VOTE][RFC] Integer Semantics
Hi! I didn’t close it because the time suited me most. I made an honest mistake and closed it 22 or so hours early because I forgot I’d opened the vote at ~23:00 and not ~02:00. Unfortunately, I realised my mistake after merging the patch. This was definitely not intentional. That's why we should not rush to merge changes on a vote when there are significant objections. There's nothing that mandated this change to be merged immediately after the voting closing, as far as I can see. Yes, we do not want to make the process endless, but it's better to wait just a bit and ensure everybody is satisfied or at least reasonably listened to. Begging people off-list to retract the votes and then close it earlier on a very marginal result definitely looks like gaming the system, even if the intent was not to do that. But the intent is only known to one person, and the actions can be seen by all, so I think it's better to take extra care here. We want the voting to be means of enhancing the consensus, not something that would leave people losing the confidence in the whole process. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE][RFC] Scalar Type Hinting with Cast
Hi! - One about having scalar typed arguements, hinted or not, simple yes/no, so we at least agree on having the feature I'm not sure how that would work. We agree on having what feature? Having coercive typing and having strict typing are two different options, working in different way and implying different coding approaches. And then there's also a third option which is a compromise approach where it is sometimes strict and sometimes not depending on a matrix of choices, and different matrices would work in different way. If I agree, for example, that coercive model is helpful - that doesn't mean I want complete strict typing, and I certainly would prefer none for now - in hope I would succeed convincing the majority in the future in the merits of coercive typing approach - than having strict model implemented now and closing the door for the coercive one forever. So I don't see how at least agree without specifying what we agreeing on works out. To be more clear: We must get a decision here. I am convinced that this is a top requested feature, since very long. Delay it forever Is there any data to support this conviction that this is not merely requested now and then, but it is a *top* requested feature since very long? Note that none of the languages most close to PHP have it. Also, I did a poll one on stackoverflow: http://programmers.stackexchange.com/questions/27564/what-features-would-you-like-to-have-in-php and it's not on top at all, though it is among the requested ones. However, having no consensus on it, saying let's get together and make something does not look like a good idea to me, because there are opportunity costs to prematurely having something that is not satisfactory. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Is it fair that people with no karma can vote on RFCs?
On 22 September 2014 04:32, Derick Rethans der...@php.net wrote: On Sat, 20 Sep 2014, Andrea Faulds wrote: Perhaps I’m being unfair and overthinking things, but I wonder if it is really fair for people who have no karma, i.e. not contributors to the documentation, extensions, php-src or anything else, to have the ability to vote on RFCs? I’d never suggest people without internals karma can’t vote. I think doc and peck contributors are as valued as any other contributors. However, people with no karma whatsoever (a blank people.php.net page) voting irks me. I think people's votes should only count if they have karma to the section of the code that the RFC/feature/whatever relates to. +1. I've said this plenty over the last couple of years, as IRC regulars can attest to. Ultimately, people who actually know and maintain the codebase should be making the final decisions. Which is definitely not to say that we shouldn't be listening to people outside the voting group — obviously, we should listen, and get feedback. I just don't believe that the haziness of the current process (we might give you a voting account if you meet mostly undefined criteria which no two people actually agree on, which then allows you to provide a single tick with no feedback) encourages that, and at some point we're going to end up with a feature being committed that is going to cause major headaches for day to day developers. Adam -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Is it fair that people with no karma can vote on RFCs?
On Sep 22, 2014 8:39 AM, Johannes Schlüter johan...@schlueters.de wrote: On September 22, 2014 4:21:29 PM CEST, Rafael Kassner kass...@php.net wrote: IMHO, denying non-karma people to vote is like to making PHP a company's product, or, in another words, you use what we built and shut up, because only listening people won't allow to accept/deny a particular RFC, only votes do. People surely don't comment (myself included) why they are choosing some particular option on a RFC, but they are making their opinion count, and I think this kind of democracy power shouldn't be voided. Slightly provocative: Why should I be forced to maintain code by people who don't want to maintain it themselves? Nobody is forcing you to do anything. You choose to contribute to PHP in the manner in which you do, just as other people choose to contribute in different, sometimes less obvious, ways. Probably even due to votes by people about whom I don't know anything? Mind that most maintenance work by most contributors happens in free time on a voluntarily base. And no open source doesn't mean democracy as governing model. It can. Every project is governed differently. Winston Churchill once famously said that democracy is the worst form of government, except all the others that have been tried. The democratic part is that people who don't like it can fork the project and eventually receive a higher traction. And then we can have dozens of competing PHP codebases floating around. But no, one man one vote and full equality doesn't work out. (i.e. if a modules primary maintainer vetos a change I have to mind that [which doesn't mean I have to agree in the end]) Using separated voting count isn't an option? Like only internal changes are voted only by people with karma and features/changes/small BC breaks that affects userland are allowed to anyone. This way I believe is easy to say if either internals and community agrees with the proposed change and community people are making their opinion count. There are no plans (and enough people who'd veto such plans) to close the mailing list. Everybody might state their opinion and we are happy to receive (constructive) feedback and ideas here. And yes, this can be a bit painful due to different forms of trolling but leads to better results respecting more opinions than a yes/no vote. The problem with that model is that history has consistently shown that those in power may listen, but will ultimately just do what they want, anyway. johannes -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php I feel it's also worth reminding everyone that VCS accounts generally aren't given away like candy. Most people who have that access have done something or another to earn it. --Kris
[PHP-DEV] [RFC] ZPP Failure On Overflow
Good evening again, Here’s a new RFC: https://wiki.php.net/rfc/zpp_fail_on_overflow Thoughts appreciated, as is help with the patch, though I can probably manage on my own. Thanks! -- Andrea Faulds http://ajf.me/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE][RFC] Scalar Type Hinting with Cast
On Sep 22, 2014 11:06 PM, Stas Malyshev smalys...@sugarcrm.com wrote: Hi! - One about having scalar typed arguements, hinted or not, simple yes/no, so we at least agree on having the feature I'm not sure how that would work. We agree on having what feature? Having coercive typing and having strict typing are two different options, working in different way and implying different coding approaches. And then there's also a third option which is a compromise approach where it is sometimes strict and sometimes not depending on a matrix of choices, and different matrices would work in different way. If I agree, for example, that coercive model is helpful - that doesn't mean I want complete strict typing, and I certainly would prefer none for now - in hope I would succeed convincing the majority in the future in the merits of coercive typing approach - than having strict model implemented now and closing the door for the coercive one forever. So I don't see how at least agree without specifying what we agreeing on works out. To be more clear: We must get a decision here. I am convinced that this is a top requested feature, since very long. Delay it forever Is there any data to support this conviction that this is not merely requested now and then, but it is a *top* requested feature since very long? Note that none of the languages most close to PHP have it. Most? Python has it, java too, ruby and perl not. We can continue to list those having them or not, not sure that brings much to this discussion. Also, I did a poll one on stackoverflow: http://programmers.stackexchange.com/questions/27564/what-features-would-you-like-to-have-in-php and it's not on top at all, though it is among the requested ones. However, having no consensus on it, saying let's get together and make something does not look like a good idea to me, because there are opportunity costs to prematurely having something that is not satisfactory. Everyone I asked wants it, be at conferences, UGs, or devolopers of one of the top tools or framework out there. There was also http://www.php-vote.com/browse/latest showing in the top requests. In any case, this endless discussion leads nowhere and we are not going to have anything done using such debates and arguing. Cheers, -- Pierre
[PHP-DEV] Improve PHP 7 serialization
PHP serialization is slowest in PHP Session, clients NoSQL, ... I would like to have in PHP 7, a new serialization algorithm or custom handler to serialize. My opinion is that the best choice is to use msgpack, it is +110% faster -30% data size HHVM discussed this issue, but all boils down to backward compatibility with PHP https://github.com/facebook/hhvm/issues/2654 What do you think about this, maybe it's time to change the old algorithm serialization, on something better? -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Improve PHP 7 serialization
On Sep 23, 2014 1:23 AM, Park Framework park.framew...@gmail.com wrote: PHP serialization is slowest in PHP Session, clients NoSQL, ... I would like to have in PHP 7, a new serialization algorithm or custom handler to serialize. The latter is already possible and there are many good extensions doing that. Igbinary f.e. My opinion is that the best choice is to use msgpack, it is +110% faster -30% data size HHVM discussed this issue, but all boils down to backward compatibility with PHP https://github.com/facebook/hhvm/issues/2654 What do you think about this, maybe it's time to change the old algorithm serialization, on something better? -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Is it fair that people with no karma can vote on RFCs?
Hi, On Mon, 2014-09-22 at 14:36 -0700, Kris Craig wrote: Slightly provocative: Why should I be forced to maintain code by people who don't want to maintain it themselves? Nobody is forcing you to do anything. You choose to contribute to PHP in the manner in which you do, just as other people choose to contribute in different, sometimes less obvious, ways. Right, nobody can truely enforce me doing something, still I gave some form of promise/commitment to less so since 5.3 reached EOL but still this might require me to do something. Probably even due to votes by people about whom I don't know anything? Mind that most maintenance work by most contributors happens in free time on a voluntarily base. And no open source doesn't mean democracy as governing model. It can. Every project is governed differently. Well democracy can mean so many things - in ancient Greece, the origin of democracy, only the men of a social group had a vote. Even in Switzerland, which is famous for its direct democracy, women weren't allowed to vote till 1971 (in the canton Appenzell Innerrhoden even only till 1990 for municipal issues) in others the voting power is unequally distributed (see i.e. the EU parliament where larger countries have less MEPs than smaller ones and different voting system's in different countries give different weight to citizens of different countries) Anyways this is a way different debate. Winston Churchill once famously said that democracy is the worst form of government, except all the others that have been tried. While this depends on your view on what is good - Louis XIV of France was quite happy with his, I assume. But government of a society is different from governance of a software project. One case leads to a revolution, the other to a fork. The democratic part is that people who don't like it can fork the project and eventually receive a higher traction. And then we can have dozens of competing PHP codebases floating around. That's were the social aspect comes back in - even people without a formal vote have ability to impact the project. The problem with that model is that history has consistently shown that those in power may listen, but will ultimately just do what they want, anyway. If those with power will ultimately just do what they want, anyway the official form of governance doesn't matter at all. Thanks for agreeing to that :-D But as this went to a path through European history let me reiterate and clarify what I said in a different post in this thread: The strict dependence on a vote impacts the constructive feedback for proposers negatively. It also provides no feedbackloop for leading to constructive critic being ignored, it becomes less clear whether voters were aware of that. It also makes simple contributions hard, adding quite some transactional cost for small improvements by newcomers. (then again here is no clear and objective measure what small includes) This is demotivating for all sides. The approach I have in mind is going back to a consensus model by default, allowing truly everybody to participate and giving the opportunity to call for a vote if consensus can't be reached. Given our social diversity I however think that this hardly works out as there always will be somebody calling for a vote ... obvious consequence would be a quorum for calling for a vote .. wich ends up in even more bureaucracy hell. I feel it's also worth reminding everyone that VCS accounts generally aren't given away like candy. Most people who have that access have done something or another to earn it. It depends on the time of day and position of the stars, sometimes they are thrown on people unless they run really fast, sometimes nobody looks after requests ... :) johannes -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Change checkdnsrr() $type argument behavior
Hi Kris, On a broad level, your RFC asserts that checkdnsrr() is used to determine whether or not a hostname exists, but you don't actually define exists. It seems to me you're glossing over the fact that existence is application-specific and doesn't add up to one single RR type or set of types. For example, when setting up a web hosting account (www.example.com), or, say, an organization-wide account for a web app (sharepoint.example.com) when example.com's DNS is managed by the tenant, we may want to determine whether the hostname exists: Is there an A or CNAME RR in the DNS for that hostname? [1] Of course, that A/CNAME needs to eventually point to your servers to be useful, but with this barebones, non-professional-grade check, we could at least tell the tenant they pre-created a record successfully. (Or, contrariwise, we could tell them the hostname already exists, so it may already be used by one of their other apps.) Note if checkdnsrr() did an ANY query, `true` would be meaningless in this context. It would be an instant false-positive if there were only an SOA and a coupla NSs. But when setting up a new user for a different kind of app, we may use their e-mail address (j...@example.com) as their username and we'll most certainly use it for a verification e-mail. Here, we might quick-check whether example.com exists in the mail context, giving a reasonable expectation that it will accept mail (maybe not ours, of course!): Is there an MX, A, or CNAME RR in the DNS for that hostname? [2] This is a different, perfectly valid way that a hostname may exist. Note again if checkdnsrr() defaulted to ANY, `true` would be meaningless/misleading. And also note (I'll explore this again below) that an MX record is not required to accept mail. You can't decide that a domain is SMTP-nonexistent just because there's no MX. Users will just be angry if they are already receiving mail and you tell them their address hard-failed your preflight check: warn them, perhaps, but leave it up to the SMTP layer to make those hard decisions. For another example, if you run a purpose-built DNS management app, you may want to know if a domain is in the DNS at all: Are there simply SOA and NS RRs in the DNS? This is another completely valid meaning. You wouldn't want to check for CNAME, MX, or A here, since none of them are mandatory. True, you could in theory waste your resources on an ANY query for this one. But it is not a compelling reason to have ANY be the default. For yet another example, if I'm building an SPF test tool I want to check if TXT or SPF/99 records exist for the hostname. I don't care if the hostname has CNAME, MX, or A -- in fact, a hostname w/an SPF record solely to discourage Joe Jobs doesn't need to prove its existence in any other way. I mean, that's the thing about DNS. It serves tens of different purposes. It's not possible to assume what people are looking for when they build a specialized PHP app. It could very well be that an app doesn't ever test for existence of A/CNAME, but only existence of SRV records. Or only PTRs. On one note I fully agree. The defaulting to MX sucks. But as others have pointed out it's a BC break to try to manipulate the arg list at this point in time. I think it would be good, maybe, to update the docs with something like (though less clumsy): This function's default behavior is to verify the existence of MX records for a hostname. MXs prove the domain owner's intent to receive mail. However, a result of `false` does not mean a domain *cannot* receive mail, as MXs are not mandatory. Perhaps try to condition people to be more aware of what they're looking up and why. As someone else said in the original thread, it's not too much to ask that PHP users who decide to use DNS functions know what they're looking up. Oh, and I also just caught a bug in the default behavior anyway. Gonna log that now! -- S. [1] Here and elsewhere A means A or , although as of late 2014 the IPV6 variant isn't sufficient to establish existence on the public 'Net. [2] I'm deliberately setting aside the vario us CNAME interactions with MX records, which may result in successful mail delivery in many, but not all, permutations: it may be safer to consider such setups broken, as long as you let the user confirm Yes, I vouch for my domain's setup/existence/operation even though you found problems. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Change checkdnsrr() $type argument behavior
On Mon, Sep 22, 2014 at 8:09 PM, Sanford Whiteman figureone...@gmail.com wrote: Hi Kris, On a broad level, your RFC asserts that checkdnsrr() is used to determine whether or not a hostname exists, but you don't actually define exists. It seems to me you're glossing over the fact that existence is application-specific and doesn't add up to one single RR type or set of types. For example, when setting up a web hosting account (www.example.com), or, say, an organization-wide account for a web app (sharepoint.example.com) when example.com's DNS is managed by the tenant, we may want to determine whether the hostname exists: Is there an A or CNAME RR in the DNS for that hostname? [1] Of course, that A/CNAME needs to eventually point to your servers to be useful, but with this barebones, non-professional-grade check, we could at least tell the tenant they pre-created a record successfully. (Or, contrariwise, we could tell them the hostname already exists, so it may already be used by one of their other apps.) Note if checkdnsrr() did an ANY query, `true` would be meaningless in this context. It would be an instant false-positive if there were only an SOA and a coupla NSs. But when setting up a new user for a different kind of app, we may use their e-mail address (j...@example.com) as their username and we'll most certainly use it for a verification e-mail. Here, we might quick-check whether example.com exists in the mail context, giving a reasonable expectation that it will accept mail (maybe not ours, of course!): Is there an MX, A, or CNAME RR in the DNS for that hostname? [2] This is a different, perfectly valid way that a hostname may exist. Note again if checkdnsrr() defaulted to ANY, `true` would be meaningless/misleading. And also note (I'll explore this again below) that an MX record is not required to accept mail. You can't decide that a domain is SMTP-nonexistent just because there's no MX. Users will just be angry if they are already receiving mail and you tell them their address hard-failed your preflight check: warn them, perhaps, but leave it up to the SMTP layer to make those hard decisions. For another example, if you run a purpose-built DNS management app, you may want to know if a domain is in the DNS at all: Are there simply SOA and NS RRs in the DNS? This is another completely valid meaning. You wouldn't want to check for CNAME, MX, or A here, since none of them are mandatory. True, you could in theory waste your resources on an ANY query for this one. But it is not a compelling reason to have ANY be the default. For yet another example, if I'm building an SPF test tool I want to check if TXT or SPF/99 records exist for the hostname. I don't care if the hostname has CNAME, MX, or A -- in fact, a hostname w/an SPF record solely to discourage Joe Jobs doesn't need to prove its existence in any other way. I mean, that's the thing about DNS. It serves tens of different purposes. It's not possible to assume what people are looking for when they build a specialized PHP app. It could very well be that an app doesn't ever test for existence of A/CNAME, but only existence of SRV records. Or only PTRs. On one note I fully agree. The defaulting to MX sucks. But as others have pointed out it's a BC break to try to manipulate the arg list at this point in time. I agree that it would be a BC, but I believe it would be a very minor one, as I doubt very many people are relying on the current default behavior. This minor level of BC would not be inappropriate for a major version increment, as it's expected that there will be at least some BC there. Based on your comments relating to DNS in general, it sounds like defaulting to ANY wouldn't be much better than the current default. I'm beginning to lean heavily towards removing the second voting option and limiting the scope of the RFC to just making the second argument required for this reason. What would happen is it'd throw an E_DEPRECATED for at least the remainder of 5.x, then throw the usual E_WARNING for a missing argument starting in 7.x with no default. It has been my observation that a number of good ideas (and fixes to bad ideas) have been set aside over fears of BC breakage. While I agree there's certainly a place for such caution, refusing to ever allow any BC for such improvements even in major version increments essentially ties our hands together and prevents the language from evolving past some of its negative aspects. BC is, by its very nature, a short-term concern. I doubt anybody is experiencing any problems caused by any BC that occurred between PHP 3 and PHP 4, for example. That's why I think major version increments are the ideal time to implement more long-term objectives that may carry a marginal short-term BC cost. Given that just about everyone here agrees that the current behavior is more or less ridiculous that doesn't serve any use cases not better
Re: [PHP-DEV] [RFC] Change checkdnsrr() $type argument behavior
What would happen is it'd throw an E_DEPRECATED for at least the remainder of 5.x, then throw the usual E_WARNING for a missing argument starting in 7.x with no default. Sounds OK to me now that I've noticed this: https://bugs.php.net/bug.php?id=68081 Pretty sure that's a sane report, and it's enough to make me say checkdnsrr() doesn't work now at all. -- S. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Is it fair that people with no karma can vote on RFCs?
On Mon, Sep 22, 2014 at 7:21 PM, Johannes Schlüter johan...@schlueters.de wrote: Hi, On Mon, 2014-09-22 at 14:36 -0700, Kris Craig wrote: Slightly provocative: Why should I be forced to maintain code by people who don't want to maintain it themselves? Nobody is forcing you to do anything. You choose to contribute to PHP in the manner in which you do, just as other people choose to contribute in different, sometimes less obvious, ways. Right, nobody can truely enforce me doing something, still I gave some form of promise/commitment to less so since 5.3 reached EOL but still this might require me to do something. Probably even due to votes by people about whom I don't know anything? Mind that most maintenance work by most contributors happens in free time on a voluntarily base. And no open source doesn't mean democracy as governing model. It can. Every project is governed differently. Well democracy can mean so many things - in ancient Greece, the origin of democracy, only the men of a social group had a vote. Even in Switzerland, which is famous for its direct democracy, women weren't allowed to vote till 1971 (in the canton Appenzell Innerrhoden even only till 1990 for municipal issues) in others the voting power is unequally distributed (see i.e. the EU parliament where larger countries have less MEPs than smaller ones and different voting system's in different countries give different weight to citizens of different countries) Anyways this is a way different debate. Fair enough. Winston Churchill once famously said that democracy is the worst form of government, except all the others that have been tried. While this depends on your view on what is good - Louis XIV of France was quite happy with his, I assume. But government of a society is different from governance of a software project. One case leads to a revolution, the other to a fork. Also fair enough. The democratic part is that people who don't like it can fork the project and eventually receive a higher traction. And then we can have dozens of competing PHP codebases floating around. That's were the social aspect comes back in - even people without a formal vote have ability to impact the project. But that's assuming the threat of fork will be enough, thereby keeping forks to a minimum. I'm not sure I can concur with that assumption. The problem with that model is that history has consistently shown that those in power may listen, but will ultimately just do what they want, anyway. If those with power will ultimately just do what they want, anyway the official form of governance doesn't matter at all. Thanks for agreeing to that :-D I think you misunderstood. Ignoring vote results derived from a legitimized process that was agreed to is much more difficult that ignoring a request made by some person without karma, with or without the threat of a fork. But as this went to a path through European history let me reiterate and clarify what I said in a different post in this thread: The strict dependence on a vote impacts the constructive feedback for proposers negatively. It also provides no feedbackloop for leading to constructive critic being ignored, it becomes less clear whether voters were aware of that. It also makes simple contributions hard, adding quite some transactional cost for small improvements by newcomers. (then again here is no clear and objective measure what small includes) This is demotivating for all sides. I wouldn't be against modifying the voting process to require everyone to state a brief reason for their vote in order for it to be counted. The current table could be modified to add a text column easily enough, I'm sure, and the results could display the reason next to each vote in the row. I think that would at least help mitigate the concerns you're raising here. The approach I have in mind is going back to a consensus model by default, allowing truly everybody to participate and giving the opportunity to call for a vote if consensus can't be reached. Given our social diversity I however think that this hardly works out as there always will be somebody calling for a vote ... obvious consequence would be a quorum for calling for a vote .. wich ends up in even more bureaucracy hell. I've noticed that minor changes are already made all the time without a vote being called and I don't have any problem with that, nor am I aware of anyone else who does. Perhaps we could clarify exactly when a vote is required and when it's not, but since that does not appear to have been an issue thus far, it would probably just be a solution in search of a problem. I feel it's also worth reminding everyone that VCS accounts generally aren't given away like candy. Most people who have that access have done something or another to earn it. It depends on the time of day and position of the
[PHP-DEV] Re: Re: OpenSSL bug in 5.4.33 and 5.5.17
Hi, That's a bad thing we need to fix ASAP. I think for 5.6.1 we'll revert it , if not, we'll need an RC2, which is something we usually don't do (but as this could involve security, we may do it). The fix can be merged to 5.5.18RC1, next week, to have an RC cycle if not part of a 5.6.1RC2 (tag is tomorrow) 5.6 and 5.5 actually overlap in the release weeks. 5.6 is planned on odd weeks whereas 5.5 is on even weeks. Waiting for Ferenc's advice anyway. Julien.P I have no issues with reverting at this point as that's the best route to get stable releases back on track. I thought I had fixed some really old bugs with those commits but the medicine turned out to be worse than the disease. My apologies again for letting those problems sneak into releases :/ I've got the necessary fixes lined up at this point, I just need to know how you guys would prefer to proceed on this. I can commit the relevant changes to 5.4, 5.5 and 5.6 and double-check with RMs to ensure they make it into this next set of releases or we can revert the previous commits and forget about the bug fixes altogether. Just let me know which you prefer. Thanks.
