Re: [PHP-DEV] 5.4 moving forward
On Tue, Jun 7, 2011 at 4:26 AM, Rasmus ras...@lerdorf.com wrote: On 06/06/2011 08:38 PM, Lester Caine wrote: And much like Apache, I don't consider it our job to do binary builds for people. It is very nice that a few people have volunteered to build Windows binaries and they are available on windows.php.net as a convenience, but our primary focus is the source distribution and that's where the bulk of the attention goes. If people are building critical systems that rely on binary-only releases, they really should reconsider how they do things and at the very least install a compiler on their platform of choice and learn how to build stuff themselves. As far as I know nothing that was available in 5.2 is not available in 5.3 in source form. Same for binary, the release is complete. And our builds are per se official builds. Cheers, -- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] 5.4 moving forward
On Tue, Jun 7, 2011 at 7:41 AM, Lester Caine les...@lsces.co.uk wrote: People who are building critical systems are in a position to make a choice, and THEY will not be using windows. But PHP was origianlly 'Personal Home Page' and I am sure that as many people are using PHP because of the 'personal' element. Those are the sort of people who 5 years ago could not afford to buy the M$ software to create their own builds, and even today some areas of windows can't be built with the free version. We tried to fill the gap by writing our own compilations to fill the gap, but today the problem is that there is simply no beginners tutorial that directs people to how they can get around the problems created by the current windows builds of PHP. I said that moving people forward to PHP5.3 was another thread, and is work that does need to be done, but simply kicking those people out into the cold is much as M$ does every version is not the way to treat users. Keep your bashing out of this list. Thanks. No matter the target. A SIMPLE clean set of instructions on the windows download page would be a start, updating the manual to reflect the current situation, and reporting errors to third party projects We have no control over 3rd party projects, If you find misleading or wrong informations on our sites, please report a bug. But hi jacking every thread about new php release or new features is not the way, I repeat: It is not the way. Cheers, -- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RE: Voting Process (was: [PHP-DEV] Re: Voting does not belong on the wiki! (Was: [PHP-DEV] 5.4 moving forward))
Am 05.06.2011 22:05, schrieb Zeev Suraski: - There wasn't sufficient time, or nearly any time at all - between when Brian pulled it off the attic, and when a vote was called. If my proposal is accepted, there'll have to be at least two weeks between when a clearly marked [RFC] email hits internals@, and when a vote is called. - There wasn't a clearly marked, separate [VOTE] email. - There wasn't a clear or easy way of voting. - No voting period was announced, instead, people were told to stop mess around and go vote. - The author of the RFC wasn't actively involved in the whole process (as far as I could tell); There was no official replacement proposer. These are all valid points. I'd still like to hear from others what they think about my proposal. If your proposal addresses the issue mentioned above: +1. Haven't had the time yet to read through it again, sorry. -- Sebastian BergmannCo-Founder and Principal Consultant http://sebastian-bergmann.de/ http://thePHP.cc/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] RE: Voting Process (was: [PHP-DEV] Re: Voting does not belong on the wiki! (Was: [PHP-DEV] 5.4 moving forward))
-Original Message- From: Pierre Joye [mailto:pierre@gmail.com] Sent: Monday, June 06, 2011 1:46 AM To: Zeev Suraski Cc: PHP Internals Subject: Re: Voting Process (was: [PHP-DEV] Re: Voting does not belong on the wiki! (Was: [PHP-DEV] 5.4 moving forward)) In any case, if you feel like we have to re vote, and many do as well, then so be it. Let's do that, either that, or go with the old-style +1/-1 on-list until we adopt a voting process (which should hopefully be soon). I won't get around to review edit the new RFC that Stas prepared today (very busy day), but I promise to take a stab at it tomorrow. Zeev -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] 5.4 moving forward
Stas Malyshev wrote: Speaking of which, I personally don't understand how LTS thing would work in PHP. Currently - A lot of ISP's are 'stuck' with PHP5.2 or earlier simply because pushing 5.3 caused problems/complaints from users due to the nature of the changes. While that almost certainly is due to the poor way that the some of the moves were documented, a version of 5.2 is still a preferred base for some? And this should perhaps be viewed as the current LTS branch? Certainly for windows users it IS a natural stable point! I've not looked to see what LTS Linux distributions have frozen at, but essentially that is their own choice to manage anyway? There is nothing in the current 5.2 base that would preclude previous PHP5 code being borough forward to 5.2, but certainly in my own case, moving that code TO 5.3 'clean' ready to further develop IS currently a stopper. PHP5.1.7 was MY previous freeze point as that fixed a major bug in the Firebird extension, but I only needed very minor tweaks to make all sites happy on the latest PHP5.2. MY main stumbling block here is 'register_globals' as as the code has been around for several years, and while not essential to remove while running 5.3, this IS a natural break point to force a rewrite of the core system to remove the reliance on it. That and having to support legacy windows servers ... Moving forward, the point at which an LTS-PHP5.2 is replaced by a newer 5.x is perhaps something that can't be dictated now? The main problem here is the lack of a PHP6 branch which PHP5.3 was a sort of 'son of' development. As with PHP4, some sections of users will simply not bother to change what they are using anyway, so for them, which ever version they use is an 'LTS' so an official LTS really is just a point at which major work MAY be required to switch over, so that is the point at which dropping PHP5.2.LTS needs to be considered? Can anybody make a case for anything earlier being the current LTS base? -- 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// Firebird - http://www.firebirdsql.org/index.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] 5.4 moving forward
Hi! changes. While that almost certainly is due to the poor way that the some of the moves were documented, a version of 5.2 is still a preferred base for some? And this should perhaps be viewed as the current LTS branch? Certainly for windows But a) it is not, since we don't support it. Somebody else could do the support, backport patches, etc. - but as far as PHP group is considered, this version is not supported anymore and nobody has any desire to do it as far as I know. b) we certainly couldn't know anything about it in 2006 when we released 5.2. of a PHP6 branch which PHP5.3 was a sort of 'son of' development. As with PHP4, some sections of users will simply not bother to change what they are using anyway, so for them, which ever version they use is an 'LTS' so an official LTS really is just a point at which major work MAY be required to switch over, so that is the point at which dropping PHP5.2.LTS needs to be considered? Can anybody make a case for anything earlier being the current LTS base? They can lag on any version that works for them, that's fine and if it works for them, great. However I don't see how it explains how we can declare any random version of PHP LTS upfront. If it's a new version, they won't upgrade to it anyway, so that doesn't help neither them not us, and if they're ready to upgrade, they could upgrade to any regular version and stick with it they same way they do now. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] 5.4 moving forward
Currently - A lot of ISP's are 'stuck' with PHP5.2 or earlier simply I don't know if this is really the case. I work in this industry, and most of the small to mid hosting company's use cPanel or Plesk, and both include PHP 5.3. I've personally seen very few issues moving from older PHP 5.x versions to PHP 5.3 (over about 2,000 sites, mainly small business sites). And Plesk and cPanel do not appear to have perpetual licenses available anymore, so ISPs that use these products are basically forced to update at minimum once a year, when their license expires. I guess they could still technically skip upgrades, when they are prompted, but major updates are available to them. A real issue is RHEL (and CentOS). RHEL locks the PHP major version to whatever it is when they release their major version. But they also maintain their own patches, and release their own updates, which slightly makes up for it. So RHEL6 will have whatever PHP that was around, then, which I hope is PHP 5.3 (I don't have any RHEL6 servers yet). So RHEL6 will always be PHP5.3.x based. But the update pipeline is still a few months, so it is important that each release is a good release. Plus, don't worry about the Non-Updating ISP. That is less of an issue that it once was. Tom -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] 5.4 moving forward
Stas Malyshev wrote: changes. While that almost certainly is due to the poor way that the some of the moves were documented, a version of 5.2 is still a preferred base for some? And this should perhaps be viewed as the current LTS branch? Certainly for windows But a) it is not, since we don't support it. Somebody else could do the support, backport patches, etc. - but as far as PHP group is considered, this version is not supported anymore and nobody has any desire to do it as far as I know. b) we certainly couldn't know anything about it in 2006 when we released 5.2. Currently off the shelf, 5.2.17 is the 'old stable' but for some windows users it IS the only available version. Changing the rest of the infrastructure to support PHP5.3 builds of windows is not just a matter of changing the PHP package! So while PHP may have washed it's hands of the problem, those users who are stuck in the hole still need to be supported in some way. But all that is being asked for is security fixes which seem to be a LOT less of a problem nowadays anyway? So support IS just a matter of maintaining availability to it and the correct builds of extensions that go with it. -- 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// Firebird - http://www.firebirdsql.org/index.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] 5.4 moving forward
On Mon, Jun 6, 2011 at 12:33 PM, Lester Caine les...@lsces.co.uk wrote: Stas Malyshev wrote: changes. While that almost certainly is due to the poor way that the some of the moves were documented, a version of 5.2 is still a preferred base for some? And this should perhaps be viewed as the current LTS branch? Certainly for windows But a) it is not, since we don't support it. Somebody else could do the support, backport patches, etc. - but as far as PHP group is considered, this version is not supported anymore and nobody has any desire to do it as far as I know. b) we certainly couldn't know anything about it in 2006 when we released 5.2. Currently off the shelf, 5.2.17 is the 'old stable' but for some windows users it IS the only available version. Changing the rest of the infrastructure to support PHP5.3 builds of windows is not just a matter of changing the PHP package! There is no reason not to update, absolutely none. So while PHP may have washed it's hands of the problem, those users who are stuck in the hole still need to be supported in some way. But all that is being asked for is security fixes which seem to be a LOT less of a problem nowadays anyway? So support IS just a matter of maintaining availability to it and the correct builds of extensions that go with it. No it is not only about these rather simple tasks, really not. QA, testing, etc. require consequent efforts, from many different teams. Cheers, -- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] 5.4 moving forward
Am 06.06.2011 12:46, schrieb Pierre Joye: There is no reason not to update, absolutely none. There is: http://bugs.php.net/bug.php?id=49189 Which fixes the issue by removing a feature and introducing a BC-Break. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] 5.4 moving forward
You cannot say that any kind of bugs prevent the waste majority to update from a dead cow to the current stable branch. And I'm not sure if it is actually a bug or a badly documented setting. On Mon, Jun 6, 2011 at 1:36 PM, Lars Schultz lars.schu...@toolpark.com wrote: Am 06.06.2011 12:46, schrieb Pierre Joye: There is no reason not to update, absolutely none. There is: http://bugs.php.net/bug.php?id=49189 Which fixes the issue by removing a feature and introducing a BC-Break. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] 5.4 moving forward
Am 06.06.2011 13:41, schrieb Pierre Joye: You cannot say that any kind of bugs prevent the waste majority to update from a dead cow to the current stable branch. And I'm not sure if it is actually a bug or a badly documented setting. Its not the bug that prevents moving forward but the fix of it! [2009-08-07 07:40 UTC] j...@php.net Obviously the documentation is wrong, it's PHP_INI_SYSTEM in sources since fix of bug #43227 for PHP 5.2.7. The fix of bug #43227 changed the setting from PHP_INI_PERDIR to PHP_INI_SYSTEM, which is not a fix but a workaround for something (ereg), which will probably be removed in the future and already is deprecated. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] 5.4 moving forward
Pierre Joye wrote: On Mon, Jun 6, 2011 at 12:33 PM, Lester Caineles...@lsces.co.uk wrote: Stas Malyshev wrote: changes. While that almost certainly is due to the poor way that the some of the moves were documented, a version of 5.2 is still a preferred base for some? And this should perhaps be viewed as the current LTS branch? Certainly for windows But a) it is not, since we don't support it. Somebody else could do the support, backport patches, etc. - but as far as PHP group is considered, this version is not supported anymore and nobody has any desire to do it as far as I know. b) we certainly couldn't know anything about it in 2006 when we released 5.2. Currently off the shelf, 5.2.17 is the 'old stable' but for some windows users it IS the only available version. Changing the rest of the infrastructure to support PHP5.3 builds of windows is not just a matter of changing the PHP package! There is no reason not to update, absolutely none. If you can convince the IT departments of some of the archaic council sites I am having to deal with that they do not have to stress test every part of a new system ... It's exactly the same argument FROM them as you are giving below as to why we should NOT provide support! Fortunately the problem is being eased by the replacement of the legacy windows systems with Linux servers but that is still slow going in some customer sites. In my own case since there is no external access I don't have to worry about security issues anyway so perhaps the discussion is academic, but I can't believe that I am the only person seeing this problem. So while PHP may have washed it's hands of the problem, those users who are stuck in the hole still need to be supported in some way. But all that is being asked for is security fixes which seem to be a LOT less of a problem nowadays anyway? So support IS just a matter of maintaining availability to it and the correct builds of extensions that go with it. No it is not only about these rather simple tasks, really not. QA, testing, etc. require consequent efforts, from many different teams. I think all I am asking for is that the various elements of PHP5.2.17 are more readily accessible directly from the PHP site, rather than having to scout around for things like the pecl extensions on third party sites. Perhaps I just need to push a current set of files onto my own site. This does parallel the discussion on 'bundling' extensions, and simplifying things so that individual extensions can be managed and even updated without having to update the whole of the rest of the core. -- 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// Firebird - http://www.firebirdsql.org/index.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] 5.4 moving forward
On 06/06/11 17:48, Tom Samplonius wrote: Currently - A lot of ISP's are 'stuck' with PHP5.2 or earlier simply I don't know if this is really the case. I work in this industry, and most of the small to mid hosting company's use cPanel or Plesk, and both include PHP 5.3. I've personally seen very few issues moving from older PHP 5.x versions to PHP 5.3 (over about 2,000 sites, mainly small business sites). And Plesk and cPanel do not appear to have perpetual licenses available anymore, so ISPs that use these products are basically forced to update at minimum once a year, when their license expires. I guess they could still technically skip upgrades, when they are prompted, but major updates are available to them. A real issue is RHEL (and CentOS). RHEL locks the PHP major version to whatever it is when they release their major version. But they also maintain their own patches, and release their own updates, which slightly makes up for it. So RHEL6 will have whatever PHP that was around, then, which I hope is PHP 5.3 (I don't have any RHEL6 servers yet). So RHEL6 will always be PHP5.3.x based. But the update pipeline is still a few months, so it is important that each release is a good release. Plus, don't worry about the Non-Updating ISP. That is less of an issue that it once was. Tom Quite a few Australian hosts are on 5.2. One host that a client uses runs off of H-Sphere (last release was on the 25th of May), where PHP was upgraded to 5.2.17. Another host that I talked to had no ETA on when they'd upgrade to 5.3. From what I've heard, part of the slow uptake is because a lot of hosting companies run FreeBSD, and they can't upgrade to 5.3 unless they either drop support for Zend Optimizer, or swap to a different platform. Cheers, David -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] 5.4 moving forward
Pierre Joye wrote: If you can convince the IT departments of some of the archaic council sites I am having to deal with that they do not have to stress test every part of a new system ... It's exactly the same argument FROM them as you are giving below as to why we should NOT provide support! Fortunately the problem is being eased by the replacement of the legacy windows systems with Linux servers but that is still slow going in some customer sites. There is zero difference, windows or linux does not matter at the language level. If they don't want to migrate to 5.3, win or linux does not matter. Anyway, that's off topic:) What makes you say that - has PHP5.3 suddenly started working with production releases of Apache on windows? Some site will not use third party builds which is the WHOLE problem of PHP5.3 on windows ... only PHP5.2 is available to run with a stock install of Apache. -- 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// Firebird - http://www.firebirdsql.org/index.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] 5.4 moving forward
On 06/06/11 07:27, Stas Malyshev wrote: Hi! On 2011-06-05, Pierre Joyepierre@gmail.com wrote: On Sun, Jun 5, 2011 at 5:52 PM, Philip Olsonphi...@roshambo.org wrote: I'd to say that I'm very happy to finally see such discussions happening, let sort the base (99% is done by our existing RFC about release process, let adopt it already!) and move on with 5.4. This is a prime example of what we're talking about. Several have expressed a desire to follow an Ubuntu style of branching instead of the style proposed in said RFC. This is a core issue, so the RFC is certainly not ready to adopt. So does this require a new RFC, or do the RFC proposers feel this is a key concept? I think that this RFC does not contain Ubuntu-style LTS and it doesn't look like it's author(s) support it, so it should be some different point, which may be RFCed and voted on if we see substantial support for it. Speaking of which, I personally don't understand how LTS thing would work in PHP. Does it mean we'd decide out of the blue that some version would have extended support, upfront? Like, say, we now say 5.5 would have extended support? Why would we want to do this, how would we know it? E.g., I understand if we had an option of extending support for some version post-factum, e.g., somewhere in 2015 we'd say 5.4 is so damn good and 5.5 has so many substantial changes that now we want 5.4 support to be extended another couple of years, and we feel we have people that are willing to do it. We could then talk on it and decide it, nothing prevents it. But as I understand LTS model means we'd have to decide it now, in 2011, and I don't see how it works. Could some of the proponents on this model explain it? Theoretical benefits of LTS: 1. You have a version that is supported for an extended period of time. Possibly useful for Ubuntu LTS releases and RHEL and other distros that have a 3 year lifetime. 2. Keeps disruptive changes coming in on an LTS release. The goal is that LTS is the polished result of the prior non-LTS releases. 3. Makes hosting companies feel safer offering an LTS release as it means less disruption for their users. 4. Businesses like it because it's less work for them to upgrade every 3-5 years instead of every 6-18 months. Those are the ones I can think of. Although I appreciate the model with my OS, I don't think it would work well on the application/component level. Cheers, David -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] 5.4 moving forward
On Mon, Jun 6, 2011 at 3:31 PM, Lester Caine les...@lsces.co.uk wrote: Pierre Joye wrote: If you can convince the IT departments of some of the archaic council sites I am having to deal with that they do not have to stress test every part of a new system ... It's exactly the same argument FROM them as you are giving below as to why we should NOT provide support! Fortunately the problem is being eased by the replacement of the legacy windows systems with Linux servers but that is still slow going in some customer sites. There is zero difference, windows or linux does not matter at the language level. If they don't want to migrate to 5.3, win or linux does not matter. Anyway, that's off topic:) What makes you say that - has PHP5.3 suddenly started working with production releases of Apache on windows? Some site will not use third party builds which is the WHOLE problem of PHP5.3 on windows ... only PHP5.2 is available to run with a stock install of Apache. Lester, We use apache and 5.3 smoothly and with the recent addition of rwlock in apc on windows, it runs even better and faster. I'm sorry but unless you provide bugs report with clear reproduce where we can actually try to help you, there is no chance to get anywhere with this kind of discussions. Now I would suggest to use bugs.php.net to report any issue you have on apache on windows with PHP. -- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] 5.4 moving forward
Pierre Joye wrote: We use apache and 5.3 smoothly and with the recent addition of rwlock in apc on windows, it runs even better and faster. I'm sorry but unless you provide bugs report with clear reproduce where we can actually try to help you, there is no chance to get anywhere with this kind of discussions. Now I would suggest to use bugs.php.net to report any issue you have on apache on windows with PHP. Does that include reporting windows.php.net pages? http://windows.php.net/download/ at the present time this is very clearly directing users that they have to use VC6 builds for Apache and they are only provided for PHP5.2.17 *WE* recommend using Apachelounge builds of apache, but some sites simply will not use that as it is not the recommended build from Apache. They religiously follow the rules printed on the official distributions and the download page is an official document as far as they are concerned, so they are being told to use VC6 builds. Apachelounge is not considered an official apache site :( If the situation has now changed where is this documented? Do *NOT* use VC9 version with apache.org binaries is very clearly stated on the download page. -- 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// Firebird - http://www.firebirdsql.org/index.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] 5.4 moving forward
On Mon, Jun 6, 2011 at 6:12 PM, Lester Caine les...@lsces.co.uk wrote: Pierre Joye wrote: We use apache and 5.3 smoothly and with the recent addition of rwlock in apc on windows, it runs even better and faster. I'm sorry but unless you provide bugs report with clear reproduce where we can actually try to help you, there is no chance to get anywhere with this kind of discussions. Now I would suggest to use bugs.php.net to report any issue you have on apache on windows with PHP. Does that include reporting windows.php.net pages? http://windows.php.net/download/ at the present time this is very clearly directing users that they have to use VC6 builds for Apache and they are only provided for PHP5.2.17 *WE* recommend using Apachelounge builds of apache, but some sites simply will not use that as it is not the recommended build from Apache. They religiously follow the rules printed on the official distributions and the download page is an official document as far as they are concerned, so they are being told to use VC6 builds. Apachelounge is not considered an official apache site :( There is no official binaries for apache, please understand once and for all and get over it. Apachelounge are well trusted builds using a modern compilers and the offical Apache sources. If the situation has now changed where is this documented? Do *NOT* use VC9 version with apache.org binaries is very clearly stated on the download page. And that's still true. But that has nothing to do with Apache or PHP being not stable but CRT compatibilities. In any case, if you find any bug, please report them at bugs.php.net, but that's totally unrelated to this thread. Cheers, -- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: Voting Process (was: [PHP-DEV] Re: Voting does not belong on the wiki! (Was: [PHP-DEV] 5.4 moving forward))
On 2011-06-05, Zeev Suraski z...@zend.com wrote: I'm fine if the entire 'Feature selection and development' part goes out of the RFC, but if there's any reference to how features are determined, we'd better get it right. Making changes once we've approved this RFC is going to be much tougher. This is big stuff - it's no coincidence we didn't have such guidelines for almost 15 years. Honestly there are other parts about the voting process that are much hotter potatoes than the points I brought up - such as who gets to vote, This is a tough one. I'm typically in favor of having the vote be completely open to anybody. However, since we're talking language features, there are a lot of other considerations -- internals folks will have a much better idea of what the BC and support ramifications are. Perhaps two votes should be considered? A general population vote, and an internals vote? This would show discrepancies between what users of PHP want, and how internals is voting. If internals votes against a feature that the general population has approved, I would expect to see some sort of executive summary showing what technical issues are at play that led to the internals vote. This would serve as a good historical record -- and also potentially show where bias lies within the internals community. is 50%+1 enough or do we need stronger majorities for substantial language changes (67%/75%), I think anything less than a strong majority (2/3 or 3/4) often is indicative of either ambivalence or strongly competing ideas. The question is where that threshold should be set (I'd lean towards 2/3 vote.) can someone who failed passing an RFC just put it up for another vote right away or is there some sort of a cool-off period, I'd argue a 2-3 week period in which to re-work the proposal and incorporate feedback from the prior discussion/voting periods. etc. etc. I think all of these need to be answered before we let this RFC govern how we do feature definition. Zeev -Original Message- From: Stas Malyshev [mailto:smalys...@sugarcrm.com] Sent: Sunday, June 05, 2011 11:17 PM To: Zeev Suraski Cc: Pierre Joye; PHP Internals Subject: Re: Voting Process (was: [PHP-DEV] Re: Voting does not belong on the wiki! (Was: [PHP-DEV] 5.4 moving forward)) Hi! I'd still like to hear from others what they think about my proposal. I'd like to update the Release Process RFC with these suggestions if people like them. I think these voting process additions totally make sense. But I am not sure it makes sense to put everything in one release RFC. The reason for that is that we don't want to endlessly amend and improve the RFC without having it actually agreed upon, I would rather prefer to agree on what we agree, have it as base for the future and then add other stuff. I've noticed a tendency on the list to lose the major goal behind endless amendments and tweaks and not doing what we agree on because we disagree on some minor detail. So maybe it would make sense to have release RFC separate (without spelling out the voting process there) and voting RFC separate which would define the voting process? -- Matthew Weier O'Phinney Project Lead| matt...@zend.com Zend Framework | http://framework.zend.com/ PGP key: http://framework.zend.com/zf-matthew-pgp-key.asc -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] 5.4 moving forward
Pierre Joye wrote: *WE* recommend using Apachelounge builds of apache, but some sites simply will not use that as it is not the recommended build from Apache. They religiously follow the rules printed on the official distributions and the download page is an official document as far as they are concerned, so they are being told to use VC6 builds. Apachelounge is not considered an official apache site:( There is no official binaries for apache, please understand once and for all and get over it. Apachelounge are well trusted builds using a modern compilers and the offical Apache sources. http://httpd.apache.org/download.cgi Win32 Binary IS one of the few binaries Apache supply!!! Some government sites will ONLY allow that version to be installed :( PHP5.2 installs have then been approved for use with the official apache install, so are you saying we need to go back to even earlier builds of PHP5.2 to work with this? If the situation has now changed where is this documented? Do*NOT* use VC9 version with apache.org binaries is very clearly stated on the download page. And that's still true. But that has nothing to do with Apache or PHP being not stable but CRT compatibilities. In any case, if you find any bug, please report them at bugs.php.net, but that's totally unrelated to this thread. See point above ... with the current windows situation on windows.php.net, PHP5.2.17 is the last version of php available to go with the official windows binaries from Apache? TESTING PHP5.3 on an official apache build and reporting bugs is not the problem here, since users are told not to use them at all. Since official apache builds have always worked stably for years with an 'official' build of PHP people simply expect that to continue! -- 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// Firebird - http://www.firebirdsql.org/index.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] 5.4 moving forward
Hi! Currently off the shelf, 5.2.17 is the 'old stable' but for some windows users it IS the only available version. Changing the rest of the infrastructure to 5.2.17 is unsupported. It is announced on php.net. Now, some Windows users, due to certain choices, may have to run this version - but this doesn't change the fact it's officially unsupported. So I don't see how it supports viability of LTS idea. package! So while PHP may have washed it's hands of the problem, those users who are stuck in the hole still need to be supported in some way. But all that is There's nothing to prevent anybody willing to do it from providing this support. However, the question is not if there are users with some special needs. The question is LTS, specifically: 1. Will PHP group ever willing to support a version in LTS timeframe - so far it never happened 2. How we know we'd need to support such version UPFRONT - before it's released? being asked for is security fixes which seem to be a LOT less of a problem nowadays anyway? So support IS just a matter of maintaining availability to it and the correct builds of extensions that go with it. It looks to me you are confusing the question of is LTS a viable model for PHP development with if we had LTS 5 years ago, would somebody benefit from it now. These are two different questions, and the second one is pure theoretical since we didn't and still haven't and I for one still don't understand how we could have it. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] 5.4 moving forward
On Mon, Jun 6, 2011 at 6:48 PM, Lester Caine les...@lsces.co.uk wrote: http://httpd.apache.org/download.cgi Win32 Binary IS one of the few binaries Apache supply!!! Some government sites will ONLY allow that version to be installed :( PHP5.2 installs have then been approved for use with the official apache install, so are you saying we need to go back to even earlier builds of PHP5.2 to work with this? I will repeat it a last time here, as I told it too many times already, including to you. These binaries are convenience builds and are by no mean official builds. That's not my word but the apache's guys. Cheers, -- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] 5.4 moving forward
Pierre Joye wrote: http://httpd.apache.org/download.cgi Win32 Binary IS one of the few binaries Apache supply!!! Some government sites will ONLY allow that version to be installed:( PHP5.2 installs have then been approved for use with the official apache install, so are you saying we need to go back to even earlier builds of PHP5.2 to work with this? I will repeat it a last time here, as I told it too many times already, including to you. These binaries are convenience builds and are by no mean official builds. That's not my word but the apache's guys. Please can you provide a link where THAT statement is made! The download page only makes reference to checking the security of a download by checking the signatures, and it is this level of security that is used is a statement that any of the downloads are 'clean' from what ever mirror source they are downloaded from. There is nothing on http://apache.favoritelinks.net//httpd/binaries/win32/README.html that says that the windows builds are anything other than approved distributions of the current builds of apache. Installation note for WAP have pointed new users to start with the apache download for MANY years so that is where new users will always start, and when an update is released, windows users are redirected once again to the download page. -- 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// Firebird - http://www.firebirdsql.org/index.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] 5.4 moving forward
On Mon, Jun 6, 2011 at 7:12 PM, Lester Caine les...@lsces.co.uk wrote: Please can you provide a link where THAT statement is made! Chech the php windows internals list archive as well as the httpd devel ones. This statement has been written numerous times in both lists. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] 5.4 moving forward
On Mon, Jun 6, 2011 at 7:12 PM, Lester Caine les...@lsces.co.uk wrote: Pierre Joye wrote: http://httpd.apache.org/download.cgi Win32 Binary IS one of the few binaries Apache supply!!! Some government sites will ONLY allow that version to be installed:( PHP5.2 installs have then been approved for use with the official apache install, so are you saying we need to go back to even earlier builds of PHP5.2 to work with this? I will repeat it a last time here, as I told it too many times already, including to you. These binaries are convenience builds and are by no mean official builds. That's not my word but the apache's guys. Please can you provide a link where THAT statement is made! The download page only makes reference to checking the security of a download by checking the signatures, and it is this level of security that is used is a statement that any of the downloads are 'clean' from what ever mirror source they are downloaded from. There is nothing on http://apache.favoritelinks.net//httpd/binaries/win32/README.html that says that the windows builds are anything other than approved distributions of the current builds of apache. Installation note for WAP have pointed new users to start with the apache download for MANY years so that is where new users will always start, and when an update is released, windows users are redirected once again to the download page. you can read more about this here: http://osdir.com/ml/php-windows/2011-04/msg00023.html especially this: http://marc.info/?l=apache-httpd-devm=129646769502349w=2 Tyrael
RE: [PHP-DEV] 5.4 moving forward
From: David Muir [mailto:davidkm...@gmail.com] On 06/06/11 17:48, Tom Samplonius wrote: Currently - A lot of ISP's are 'stuck' with PHP5.2 or earlier simply I don't know if this is really the case. The problem is much larger than most of us would probably like to believe. Some of the major hosts, (like GoDaddy) offer 5.3 as an htaccess swap, but many others don't. For example, Rackspace still hasn't upgraded their Cloud Sites offering and it seems that Bluehost is also still on 5.2.
Re: [PHP-DEV] 5.4 moving forward
Pierre Joye wrote: Please can you provide a link where THAT statement is made! Chech the php windows internals list archive as well as the httpd devel ones. This statement has been written numerous times in both lists. PERHAPS such important information could be made available to REAL USERS? There has never been any public statement to that effect! Until you came on the scene I had never even had to look at compiling anything in the FWAP or FLAP stack, everything just worked from the precompiled downloads linked to by the tutorials. EVEN the php manual STILL starts a windows apache install with a download of the .msi from apache! That is one of the first hit on google and bing for install apache php on windows and every one of the links I checked starting with Drupal say Download the Apache Windows MSI Installer from Apache.org. I've updated my own FWAP installation tutorial to use the Apachelounge installer but one has to go a long way down the google or bing results to find any reference to apachelounge at all :( So a few people saying that this is not an official version of Apache makes no difference to the probably millions of users who follow the directions to install Apache and then find problems adding PHP to it ... and start asking 'where is the VC6 version of PHP5.3' everywhere other than on the PHP lists. -- 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// Firebird - http://www.firebirdsql.org/index.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] 5.4 moving forward
On Mon, Jun 6, 2011 at 8:11 PM, Lester Caine les...@lsces.co.uk wrote: PERHAPS such important information could be made available to REAL USERS? There has never been any public statement to that effect! For the 10th time, please stop to uppercase every 2nd word. Until you came on the scene I had never even had to look at compiling anything in the FWAP or FLAP stack, After months of endless discussions, the reasons why we stop to support a 16 years old compiler (please notice the we, not the I) are still black magic to your eyes. I'm sorry that I did not succeed to explain it better. However I ask you, strongly, now to stop to pollute this thread with totally unrelated topics. Thanks for your understanding. -- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] 5.4 moving forward
Pierre Joye wrote: However I ask you, strongly, now to stop to pollute this thread with totally unrelated topics. Thanks for your understanding. This is something of a rather important point since PHP has always been very strongly related to Apache so it is totally related to a discussion of moving PHP forward. Currently the mainstream information is so far adrift of the present situation that at it needs to be addressed. A starting point would be to bring all of the PHP manual information in line with the current situation and point people to the preferred installation paths rather than telling people to use steps that do not actually get to a working PHP5.3 setup? And starting to push out 5.4 will increase peoples requests to getting things working with exiting windows/apache/php5.2 setups. Does anybody other than Pierre disagree with the point that currently the mainstream windows installation paths are something of a mess and needs to be updated in some way? I've been updating my own installation guides, but I had not realised just how many other PHP projects provide windows installation guides that no longer work. Not having been using windows myself on new builds for some time, I had not updated and tested clean installs and it's only recently I've found how out of date things are :( I've been getting emails from people asking why my guides were not working hence the need to address this and get back to a working situation. -- 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// Firebird - http://www.firebirdsql.org/index.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] 5.4 moving forward
Hi! Media Temple's Grid servers still default to PHP 4.4.9. With the option of using 5.2.16, but you have to explicitly tell it to use that version in your .htaccess file. This is pretty bad, but LTS would only make this problem worse - imagine if 4.4 were LTS, they'd say oh, we are installing only long-term versions, we are long-term vision people!. Now at least they don't have the excuse :) -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] 5.4 moving forward
On 06/06/2011 01:48 AM, Tom Samplonius wrote: So RHEL6 will have whatever PHP that was around, then, which I hope is PHP 5.3 (I don't have any RHEL6 servers yet). So RHEL6 will always be PHP5.3.x based. RHEL 6.0's php-* packages are PHP 5.3.2. RHEL 6.1's uses PHP 5.3.3. RHEL 5.6 has a set of php53-* packages with PHP 5.3.3. This augments the RHEL 5.x php-* packages that are PHP 5.1.6. Chris PS -- Email: christopher.jo...@oracle.com Tel: +1 650 506 8630 Blog: http://blogs.oracle.com/opal/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] 5.4 moving forward
Hello. A PHP developers view on windows installation: it's screwed as hell right now. I use apache + php for my developing envoirment on Windows 7. Guys - I spend 1.5, freaking 1.5 hours setting up apache + php!!! essentially i just had to download and try multiple binaries for windows to find the right one. The first time I did that it was two evenings. Now i know that i need a VC9 threaded version and i haveto go to the Perries page to get extensions. Sometimes you have to fish the google to find some extenension that works and not fails to load. To my liking the situation is ridicilous. The manual has to be updated and windows support should be restored to full strength as it was. Many developers work on windows because many of us do not have the time or will to dive into linux and fine toon it and spend weeks finding software that is adiquite. And mostly windows based software is usually winning in features and quality, and most importantly - usability. Tried, but had to return to windows. Maybe you just don't get that kind of feedback becase internals list isn't what usually people read. Set up an official forums and people will start to post. 06.06.2011 20:51 пользователь Stas Malyshev smalys...@sugarcrm.com написал: Hi! Media Temple's Grid servers still default to PHP 4.4.9. With the option of using 5.2.16, but you have to explicitly tell it to use that version in your .htaccess file. This is pretty bad, but LTS would only make this problem worse - imagine if 4.4 were LTS, they'd say oh, we are installing only long-term versions, we are long-term vision people!. Now at least they don't have the excuse :) -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Voting Process (was: [PHP-DEV] Re: Voting does not belong on the wiki! (Was: [PHP-DEV] 5.4 moving forward))
On Sun, Jun 5, 2011 at 5:20 PM, Pierre Joye pierre@gmail.com wrote: I'd to go with a 60% for language syntax, 50+1 for new exts or sapis. Other question is who can vote. For one, I like to have external people being able to vote, like frameworks/apps lead developers as well as @php.net in general (docs people at the same level than core devs, no diff). I have a little proposition here. I'm not —at least currently— known for any app or framework, but I'd like my voice to count, that is, if and only if the rest of the community thinks I make sane arguments that are worth considering. I'm perfectly aware that the fame one could gain from taking production code to visible success should be an indicator of an educated opinion, however, I think this might lead to a closed group who can vote, and I like the openness of this community, even if the general process is chaotic, it still gets the warm and fuzzy feeling of an open source community. OTOH, if a completely open group's votes were all considered, the final decision could just end up being a matter of numbers outnumbering other numbers. If I get it right, this is the current problem. So my proposal is that the voting privilege could be given on the basis of a *web of trust*, and if I'm not mistaken this is a little like what the concept of karma works here (I'm fairly new here). Not sure if there should be a voting to elect voters or if it could/should be something more lax, but I don't think the requirement to vote should be fame. Best regards, David
Re: [PHP-DEV] 5.4 moving forward
Hi! A PHP developers view on windows installation: it's screwed as hell right now. I use apache + php for my developing envoirment on Windows 7. Guys - I spend 1.5, freaking 1.5 hours setting up apache + php!!! essentially i just As much as I appreciate everybody taking this opportunity to vent about their troubles with Apache on Windows, could we not hijack this topic - which was about release management and in particular LTS - and turn it into Apache on Windows topic? We can have separate Apache on Windows topic where people can share their pain and trade solutions. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Voting Process (was: [PHP-DEV] Re: Voting does not belong on the wiki! (Was: [PHP-DEV] 5.4 moving forward))
On Mon, Jun 6, 2011 at 12:27 PM, dukeofgaming dukeofgam...@gmail.com wrote: I have a little proposition here. I'm not —at least currently— known for any app or framework, but I'd like my voice to count, that is, if and only if the rest of the community thinks I make sane arguments that are worth considering. I'm perfectly aware that the fame one could gain from taking production code to visible success should be an indicator of an educated opinion, however, I think this might lead to a closed group who can vote, and I like the openness of this community, even if the general process is chaotic, it still gets the warm and fuzzy feeling of an open source community. OTOH, if a completely open group's votes were all considered, the final decision could just end up being a matter of numbers outnumbering other numbers. If I get it right, this is the current problem. So my proposal is that the voting privilege could be given on the basis of a *web of trust*, and if I'm not mistaken this is a little like what the concept of karma works here (I'm fairly new here). Not sure if there should be a voting to elect voters or if it could/should be something more lax, but I don't think the requirement to vote should be fame. I'm similarly placed (as are many here I think), in the sense that I have not done any internals work and I am not one of the lead devs for a well-known project. Much as I think my opinions are great, I don't believe we should have a vote or, if we do, that it shouldn't count for as much as others', for the following reasons: - Long-term commitment: we want people voting who (1) know the history of past PHP discussions on topics and why they were rejected or postponed, (2) understand the PHP way, and (3) have shown commitment to *maintaining* PHP - Perspective: developing *with* PHP is not the same as developing *for* PHP internals. Feasibility, interoperability, maintenance concerns, and more are things that, as long as I've read the list, are often misunderstood or downplayed by people who develop *with* PHP and want a shiny new feature (including me). - Unified vision: we want people who are taking the whole PHP picture into account to be the ones doing the voting. Much of the volume on the list is very narrowly focused - this is a good thing for discussion of specific features, but a bad thing for picking which features to include in PHP. So, I would advocate a white list of core devs for formal voting (of which, for example, I would not be a member). I think this mailing list has grown sufficiently that public opinion can be gauged from here: everyone can write their opinion without giving them voting privileges. If you haven't already, I recommend you read the (incredibly long) discussions from last summer on type-hinting. They convinced me that sometimes a feature that sounds good is simply not a good fit for PHP for reasons which many did not (still do not?) understand. Chad Fulton -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Voting Process (was: [PHP-DEV] Re: Voting does not belong on the wiki! (Was: [PHP-DEV] 5.4 moving forward))
On 2011-06-06, Chad Fulton chadful...@gmail.com wrote: So, I would advocate a white list of core devs for formal voting (of which, for example, I would not be a member). I think this mailing list has grown sufficiently that public opinion can be gauged from here: everyone can write their opinion without giving them voting privileges. If you haven't already, I recommend you read the (incredibly long) discussions from last summer on type-hinting. They convinced me that sometimes a feature that sounds good is simply not a good fit for PHP for reasons which many did not (still do not?) understand. I think your analysis is great. That said, I think if this is the route ultimately taken, any time an RFC is voted out, a summary of the _technical_ reasons for denying it should be provided. Usually there are very good ones -- but this information can be invaluable to anybody who may want to ressurect the RFC in the future to ensure they don't hit the same pitfalls. -- Matthew Weier O'Phinney Project Lead| matt...@zend.com Zend Framework | http://framework.zend.com/ PGP key: http://framework.zend.com/zf-matthew-pgp-key.asc -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] 5.4 moving forward
Stas Malyshev wrote: As much as I appreciate everybody taking this opportunity to vent about their troubles with Apache on Windows, could we not hijack this topic - which was about release management and in particular LTS - and turn it into Apache on Windows topic? We can have separate Apache on Windows topic where people can share their pain and trade solutions. The reason for the connection is simple ... currently PHP5.2 IS the LTS version for MANY users who are running windows based apache servers. Which is the only reason that I was suggesting that this is part of the discussion on setting a current LTS. It's not just chnages to the internal operation of PHP that causes problems for users, simply installing a working copy is somewhat important? Moving those users forward to the current builds is another thread that needs addressing. -- 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// Firebird - http://www.firebirdsql.org/index.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] 5.4 moving forward
Hi! The reason for the connection is simple ... currently PHP5.2 IS the LTS version for MANY users who are running windows based apache servers. Which is the only If that's what you mean by LTS, then discussing it is meaningless, as nothing here depends on us - the users will do it regardless and against out advice anyway. So why bother? Anything can be LTS. BTW, what do you think LTS means? Especially the S part? -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] 5.4 moving forward
Stas Malyshev wrote: Hi! The reason for the connection is simple ... currently PHP5.2 IS the LTS version for MANY users who are running windows based apache servers. Which is the only If that's what you mean by LTS, then discussing it is meaningless, as nothing here depends on us - the users will do it regardless and against out advice anyway. So why bother? Anything can be LTS. BTW, what do you think LTS means? Especially the S part? For many of us, the 5.2 branch HAS been the 'long term stability' version of PHP since our essential extensions were dropped from PHP5.3. For those people who would have difficulty replacing their current windows apache installation perhaps because it's provided as part of their hosting, then simply maintaining 5.2 as an available branch is important to them. Any dangerous security issue should be sorted because they have no chance of changing to a later build through no fault of their own. -- 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// Firebird - http://www.firebirdsql.org/index.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] 5.4 moving forward
Hi! For many of us, the 5.2 branch HAS been the 'long term stability' version of PHP Any version beyond it's support period would be long term stability (as in pining for the fjords stability) by definition. If somebody want to backport patches and provide builds for it for any period he likes - sure, but nobody volunteered so far, AFAIK. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] 5.4 moving forward
On 06/05/2011 03:27 PM, Stas Malyshev wrote: This is a prime example of what we're talking about. Several have expressed a desire to follow an Ubuntu style of branching instead of the style proposed in said RFC. This is a core issue, so the RFC is certainly not ready to adopt. So does this require a new RFC, or do the RFC proposers feel this is a key concept? I think that this RFC does not contain Ubuntu-style LTS and it doesn't look like it's author(s) support it, so it should be some different point, which may be RFCed and voted on if we see substantial support for it. Speaking of which, I personally don't understand how LTS thing would work in PHP. Does it mean we'd decide out of the blue that some version would have extended support, upfront? Like, say, we now say 5.5 would have extended support? Why would we want to do this, how would we know it? E.g., I understand if we had an option of extending support for some version post-factum, e.g., somewhere in 2015 we'd say 5.4 is so damn good and 5.5 has so many substantial changes that now we want 5.4 support to be extended another couple of years, and we feel we have people that are willing to do it. We could then talk on it and decide it, nothing prevents it. But as I understand LTS model means we'd have to decide it now, in 2011, and I don't see how it works. Could some of the proponents on this model explain it? The trunk development and the branching policy process isn't adequately captured in the RFC. This is a gray area that should be included. It's a pity little of the mail list discussion seems to have been merged back to the RFC as clarifications, or in a comment answer section. Chris -- Email: christopher.jo...@oracle.com Tel: +1 650 506 8630 Blog: http://blogs.oracle.com/opal/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] 5.4 moving forward
Stas Malyshev wrote: For many of us, the 5.2 branch HAS been the 'long term stability' version of PHP Any version beyond it's support period would be long term stability (as in pining for the fjords stability) by definition. If somebody want to backport patches and provide builds for it for any period he likes - sure, but nobody volunteered so far, AFAIK. This begs the question Who decided that the only vesion of PHP available to a potentially large section of the user base should be end of lifed? When was it voted on and was the problems of using a later version on some existing platforms even considered in that discussion? This I think is the crux of all the problems ... nobody actaully considers the end users at all? -- 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// Firebird - http://www.firebirdsql.org/index.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] 5.4 moving forward
On 06/06/2011 08:38 PM, Lester Caine wrote: Stas Malyshev wrote: For many of us, the 5.2 branch HAS been the 'long term stability' version of PHP Any version beyond it's support period would be long term stability (as in pining for the fjords stability) by definition. If somebody want to backport patches and provide builds for it for any period he likes - sure, but nobody volunteered so far, AFAIK. This begs the question Who decided that the only vesion of PHP available to a potentially large section of the user base should be end of lifed? When was it voted on and was the problems of using a later version on some existing platforms even considered in that discussion? This I think is the crux of all the problems ... nobody actaully considers the end users at all? We did, the folks who actually work on this stuff. In order to move forward we need to drop old branches. Right now we are working on 3 branches, which has proven over time to be right at the limit of what we can handle. It may even be a branch more than we can handle. And much like Apache, I don't consider it our job to do binary builds for people. It is very nice that a few people have volunteered to build Windows binaries and they are available on windows.php.net as a convenience, but our primary focus is the source distribution and that's where the bulk of the attention goes. If people are building critical systems that rely on binary-only releases, they really should reconsider how they do things and at the very least install a compiler on their platform of choice and learn how to build stuff themselves. As far as I know nothing that was available in 5.2 is not available in 5.3 in source form. -Rasmus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] 5.4 moving forward
On 07/06/11 01:49, Stas Malyshev wrote: Hi! Currently off the shelf, 5.2.17 is the 'old stable' but for some windows users it IS the only available version. Changing the rest of the infrastructure to 5.2.17 is unsupported. It is announced on php.net. Now, some Windows users, due to certain choices, may have to run this version - but this doesn't change the fact it's officially unsupported. So I don't see how it supports viability of LTS idea. Yes, and one week after support ending with announcement of 5.2.15, 5.2.16 was released again claiming that support has ended. And then a month later 5.2.17 was released, but no longer mentions that support has ended. Not too surprising then if people incorrectly assume that critical issues will continue to be fixed for 5.2. package! So while PHP may have washed it's hands of the problem, those users who are stuck in the hole still need to be supported in some way. But all that is There's nothing to prevent anybody willing to do it from providing this support. However, the question is not if there are users with some special needs. The question is LTS, specifically: 1. Will PHP group ever willing to support a version in LTS timeframe - so far it never happened 5.2 was supported for about 5 years, which is what one would expect from an LTS release, so yes. It has effectively already happened. 2. How we know we'd need to support such version UPFRONT - before it's released? Because you say upfront how long the release will be supported. This is fairly straight-forward for any project using timed releases, which by the looks of it, is what the RFC is suggesting. How does Canonical know which Ubuntu release will be LTS? Because they decided every 4th release will be LTS. It's really not any more complicated than that. Maybe confusion is because in the past PHP has not followed timed releases, so there's no knowing how long it will be until the next version comes out. The best you can do then is promise x months of support after the next version is released. being asked for is security fixes which seem to be a LOT less of a problem nowadays anyway? So support IS just a matter of maintaining availability to it and the correct builds of extensions that go with it. It looks to me you are confusing the question of is LTS a viable model for PHP development with if we had LTS 5 years ago, would somebody benefit from it now. These are two different questions, and the second one is pure theoretical since we didn't and still haven't and I for one still don't understand how we could have it. Not intentionally, but 5.2 was supported for the time-frame expected from an LTS release. That may have given the impression that 5.3 will be supported for 5 years too, and therefore hosts can upgrade within a year or two after the release and still expect to get updates for the next 3-4 years. One thing that I think would help drive adoption of newer versions is EOL being very clearly stated. As it stands we don't know if 5.3 will continue to be supported for the next 5 years, or if it will be EOL next year. All we have to go on is what's happened in the past, and although 5.2's lifetime was an anomaly, it seems it's what people have come to expect. Cheers, David -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] 5.4 moving forward
Rasmus wrote: On 06/06/2011 08:38 PM, Lester Caine wrote: Stas Malyshev wrote: For many of us, the 5.2 branch HAS been the 'long term stability' version of PHP Any version beyond it's support period would be long term stability (as in pining for the fjords stability) by definition. If somebody want to backport patches and provide builds for it for any period he likes - sure, but nobody volunteered so far, AFAIK. This begs the question Who decided that the only vesion of PHP available to a potentially large section of the user base should be end of lifed? When was it voted on and was the problems of using a later version on some existing platforms even considered in that discussion? This I think is the crux of all the problems ... nobody actaully considers the end users at all? We did, the folks who actually work on this stuff. In order to move forward we need to drop old branches. Right now we are working on 3 branches, which has proven over time to be right at the limit of what we can handle. It may even be a branch more than we can handle. And much like Apache, I don't consider it our job to do binary builds for people. It is very nice that a few people have volunteered to build Windows binaries and they are available on windows.php.net as a convenience, but our primary focus is the source distribution and that's where the bulk of the attention goes. If people are building critical systems that rely on binary-only releases, they really should reconsider how they do things and at the very least install a compiler on their platform of choice and learn how to build stuff themselves. As far as I know nothing that was available in 5.2 is not available in 5.3 in source form. People who are building critical systems are in a position to make a choice, and THEY will not be using windows. But PHP was origianlly 'Personal Home Page' and I am sure that as many people are using PHP because of the 'personal' element. Those are the sort of people who 5 years ago could not afford to buy the M$ software to create their own builds, and even today some areas of windows can't be built with the free version. We tried to fill the gap by writing our own compilations to fill the gap, but today the problem is that there is simply no beginners tutorial that directs people to how they can get around the problems created by the current windows builds of PHP. I said that moving people forward to PHP5.3 was another thread, and is work that does need to be done, but simply kicking those people out into the cold is much as M$ does every version is not the way to treat users. A SIMPLE clean set of instructions on the windows download page would be a start, updating the manual to reflect the current situation, and reporting errors to third party projects that also return the wrong instructions would at least provide the assistance to users who are not in a position to build the complete compile chain that is required to work form source. Heck mine is broken again and I don't have time to sort out why, so I've not been able to update some stuff for others :( -- 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// Firebird - http://www.firebirdsql.org/index.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Voting does not belong on the wiki! (Was: [PHP-DEV] 5.4 moving forward)
On Jun 3, 2011, at 4:43 AM, Derick Rethans der...@php.net wrote: On Fri, 3 Jun 2011, Stas Malyshev wrote: - a call to vote is easily drowned out on the ML with all the noise I read the same ML as you do :) Using threaded email client it is very easy to separate new threads and see calls for votes. That is subjective. And even with a threaded client, if there are 80+ new messages then the call for vote is drowned out. *Requiring* something like [VOTE] in the subject helps, as then you can set-up a filter. And if it's a requirement, every call without [VOTE] in the subject is invalid. (Easy to fix if somebody forgot it as well). It would expose this kind of thing. Why not setup a different ML that is announce-only except a few people, just to announce votes?
RE: [PHP-DEV] Re: Voting does not belong on the wiki! (Was: [PHP-DEV] 5.4 moving forward)
On Jun 4, 2011, at 3:07 AM, Pierre Joye wrote: On Sat, Jun 4, 2011 at 5:46 AM, Stas Malyshev smalys...@sugarcrm.com wrote: [VOTE] is a good idea, let's make it [VOTE]. There is no plugin used for it yet, and that's my problem with it. Well, votes aren't announced yet either :) I'll try to get it set up ASAP and see how it works, before announcing the vote. It looks good in description at least. Please keep them in the wiki as we planed to do. THere are plugins and it is very easy to manage, allows per section voting etc. I'm hopeful people will continue to understand the RFC definition: - RFC: Request For Comments And while doing so, not revert to a vote (RFV?) simply because discussing a topic can get messy. Voting has clear winners and losers with potential loss for improvements. That and you must then worry about who can and cannot vote (i.e., non-inclusive community). It's rare that we've required a formal vote, so I fear we will now implement voting at inappropriate times rather than allow a consensus to be reached. Also, people should be given a reasonable opportunity to offer an alternative RFC. I agree wholeheartedly with Philip - and that does not mean that my intention is to derail a healthy voting process. Some of you may have followed the twitter conversation that Pierre and I had at the end of last week; In my opinion, this dry (or partially wet) run that we had in the last few days of a voting process pointed to several deficiencies that need to be addressed in the RFC release process that need to be addressed before we move on. First, we need to make sure that the RFC is properly evaluated by the members of internals@, and that there's enough time for the RFC to be discussed here on the list. As Philip pointed out - an RFC is request for comments, not a request for a vote. This list isn't supposed to become some sort of a bureaucratic voting body, but where new ideas are discussed, refined, and eventually - accepted or rejected. I realize that some here are worried that discussions can be endless, but we shouldn't go for the other extreme of having no discussion. For this reason, I propose the following: - There'd be a minimum amount of time between when an RFC is brought up on this list and when it's voted on (say 2wks). The effective date will not be when the RFC was published on wiki.php.net/rfc - but when it was announced on internals@, by the author, with the intention of voting on it. It doesn't matter if the RFC was up there for 2yrs, or discussed 20 times in the past - if the intention is to go for a vote, there needs to be time for a healthy discussion, as opposed to just yes/no. This will also allow for people who are attending conferences, are on vacations, etc. - not to miss an entire discussion/vote. - The announcement will be done in a way that's easy to flag follow, e.g. - by [RFC] in the subject line followed by the title of the RFC. Again, the effective date will start from the time this email is sent to the list, not any other time. - Eventually, it'll be up to the author to move ahead and call a vote on the RFC. That means that if the author feels that there's still healthy discussion going on, he can decide not to move ahead to request a vote after 2wks, but after 3 or 4wks. On the other hand, if he feels that the discussion is being derailed - he can always move ahead to a vote as long as the minimum discussion time elapsed. - In my opinion, only RFCs with active proposers should be discussed. If the proposer of an RFC is no longer leading the effort to get this RFC accepted - it should either find a new proposer, or it should be abandoned. Secondly - the announcement of the vote - I very much agree with Derick that having someone announce a vote in a thread of 50 messages (or even 10) messages is impractical. It needs to be a separate thread, and it has to be clearly marked - a simple subject prefix like [VOTE] followed by the title of the RFC should do. Thirdly, there's the voting mechanism itself. The voting experience has to be nicer than editing a wiki page, I think we all agree about that... The plugin Stas installed gets us something better than that, but ideally, if we could provide single-click URLs in the [VOTE] email itself for voting yay or nay that would be great. Last, we need a predefined time for voting. It too has to be sufficiently long so that everyone has a chance to cast their votes, and on the other end shouldn't be endless. I think the 1wk should do. If there's anybody who feels that the minimum 3wks period is too slow, it isn't. Any mistake we make can take a decade to fix, because downwards compatibility is such an important factor in PHP's design goals. Taking a bit of time to discuss the merits and contents of each RFC is well worth it, especially if we have rules and predefined schedules - so that discussions can't
Re: [PHP-DEV] Re: Voting does not belong on the wiki! (Was: [PHP-DEV] 5.4 moving forward)
On Sun, Jun 5, 2011 at 4:18 PM, Zeev Suraski z...@zend.com wrote: Some of you may have followed the twitter conversation that Pierre and I had at the end of last week; In my opinion, this dry (or partially wet) run that we had in the last few days of a voting process pointed to several deficiencies that need to be addressed in the RFC release process that need to be addressed before we move on. Fully agreed and it was the case for the array stuff and a consensus is clear here, and in favour of one the proposals. To make the point straight. First, we need to make sure that the RFC is properly evaluated by the members of internals@, and that there's enough time for the RFC to be discussed here on the list. As Philip pointed out - an RFC is request for comments, not a request for a vote. This list isn't supposed to become some sort of a bureaucratic voting body, but where new ideas are discussed, refined, and eventually - accepted or rejected. I realize that some here are worried that discussions can be endless, but we shouldn't go for the other extreme of having no discussion. Right, that's why we have draft, on discussions status and we should add a vote status. Maybe clearly document that as well on the main RFCs page to avoid badly proposed RFC to end in a voting phase too early or at all. - There'd be a minimum amount of time between when an RFC is brought up on this list and when it's voted on (say 2wks). The effective date will not be when the RFC was published on wiki.php.net/rfc - but when it was announced on internals@, by the author, with the intention of voting on it. It doesn't matter if the RFC was up there for 2yrs, or discussed 20 times in the past - if the intention is to go for a vote, there needs to be time for a healthy discussion, as opposed to just yes/no. This will also allow for people who are attending conferences, are on vacations, etc. - not to miss an entire discussion/vote. Agreed. - The announcement will be done in a way that's easy to flag follow, e.g. - by [RFC] in the subject line followed by the title of the RFC. Again, the effective date will start from the time this email is sent to the list, not any other time. Afaict, it is the case already. - Eventually, it'll be up to the author to move ahead and call a vote on the RFC. That means that if the author feels that there's still healthy discussion going on, he can decide not to move ahead to request a vote after 2wks, but after 3 or 4wks. On the other hand, if he feels that the discussion is being derailed - he can always move ahead to a vote as long as the minimum discussion time elapsed. - In my opinion, only RFCs with active proposers should be discussed. If the proposer of an RFC is no longer leading the effort to get this RFC accepted - it should either find a new proposer, or it should be abandoned. Yes, the authors should have the hand on the process, not some random not related developers, while anyone could be able to help to push an idea. Secondly - the announcement of the vote - I very much agree with Derick that having someone announce a vote in a thread of 50 messages (or even 10) messages is impractical. It needs to be a separate thread, and it has to be clearly marked - a simple subject prefix like [VOTE] followed by the title of the RFC should do. Agreed. Thirdly, there's the voting mechanism itself. The voting experience has to be nicer than editing a wiki page, I think we all agree about that... The plugin Stas installed gets us something better than that, but ideally, if we could provide single-click URLs in the [VOTE] email itself for voting yay or nay that would be great. It is the case now. We have a poll plugin installed. To be proven to fulfill our needs but as far as I remember, moodle2 does the job pretty well. Last, we need a predefined time for voting. It too has to be sufficiently long so that everyone has a chance to cast their votes, and on the other end shouldn't be endless. I think the 1wk should do. Again, agreed. Deciding things between Friday evening and Monday morning is simply not possible nor correct, for example. If there's anybody who feels that the minimum 3wks period is too slow, it isn't. Any mistake we make can take a decade to fix, because downwards compatibility is such an important factor in PHP's design goals. Taking a bit of time to discuss the merits and contents of each RFC is well worth it, especially if we have rules and predefined schedules - so that discussions can't drag forever. Even more true for languages related RFCs, they are critical (and irreversible) and we should proceed with much caution than anything else. I'd to say that I'm very happy to finally see such discussions happening, let sort the base (99% is done by our existing RFC about release process, let adopt it already!) and move on with 5.4. Cheers, -- Pierre
Re: [PHP-DEV] Re: Voting does not belong on the wiki! (Was: [PHP-DEV] 5.4 moving forward)
On Sun, Jun 5, 2011 at 17:20, Pierre Joye pierre@gmail.com wrote: On Sun, Jun 5, 2011 at 4:18 PM, Zeev Suraski z...@zend.com wrote: Some of you may have followed the twitter conversation that Pierre and I had at the end of last week; In my opinion, this dry (or partially wet) run that we had in the last few days of a voting process pointed to several deficiencies that need to be addressed in the RFC release process that need to be addressed before we move on. Fully agreed and it was the case for the array stuff and a consensus is clear here, and in favour of one the proposals. To make the point straight. Say what? Do people even know what they were voting for? I have absolutely no idea whatsoever what is being voted on, so I haven't yet. - The announcement will be done in a way that's easy to flag follow, e.g. - by [RFC] in the subject line followed by the title of the RFC. Again, the effective date will start from the time this email is sent to the list, not any other time. Afaict, it is the case already. Definitely not. There is so much discussion about the array stuff now that I have no idea what is being voted on.. People started counting votes before the discussion even began. -Hannes -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Voting does not belong on the wiki! (Was: [PHP-DEV] 5.4 moving forward)
On Jun 5, 2011, at 8:20 AM, Pierre Joye wrote: I'd to say that I'm very happy to finally see such discussions happening, let sort the base (99% is done by our existing RFC about release process, let adopt it already!) and move on with 5.4. This is a prime example of what we're talking about. Several have expressed a desire to follow an Ubuntu style of branching instead of the style proposed in said RFC. This is a core issue, so the RFC is certainly not ready to adopt. So does this require a new RFC, or do the RFC proposers feel this is a key concept? Regards, Philip -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Voting does not belong on the wiki! (Was: [PHP-DEV] 5.4 moving forward)
On Sun, Jun 5, 2011 at 5:46 PM, Hannes Magnusson hannes.magnus...@gmail.com wrote: On Sun, Jun 5, 2011 at 17:20, Pierre Joye pierre@gmail.com wrote: On Sun, Jun 5, 2011 at 4:18 PM, Zeev Suraski z...@zend.com wrote: Some of you may have followed the twitter conversation that Pierre and I had at the end of last week; In my opinion, this dry (or partially wet) run that we had in the last few days of a voting process pointed to several deficiencies that need to be addressed in the RFC release process that need to be addressed before we move on. Fully agreed and it was the case for the array stuff and a consensus is clear here, and in favour of one the proposals. To make the point straight. Say what? Do people even know what they were voting for? I have absolutely no idea whatsoever what is being voted on, so I haven't yet. If you do not understand what has been discussed and can't vote, that's not my or our problem. Nothing I can do will help you here. - The announcement will be done in a way that's easy to flag follow, e.g. - by [RFC] in the subject line followed by the title of the RFC. Again, the effective date will start from the time this email is sent to the list, not any other time. Afaict, it is the case already. Definitely not. There is so much discussion about the array stuff now that I have no idea what is being voted on.. People started counting votes before the discussion even began. Please, and I mean it, stop to state wrong and misleading information. There is a page where people votes and have changed their votes, https://wiki.php.net/rfc/shortsyntaxforarrays/vote. There is a clear and obvious consensus, like or not. Cheers, -- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] RE: Voting Process (was: [PHP-DEV] Re: Voting does not belong on the wiki! (Was: [PHP-DEV] 5.4 moving forward))
Pierre, I'm happy that we agree pretty much completely about the clarifications updates needed for the RFC. I do however want to point out that the problematic way the short array syntax RFC was executed was the key reason that made me feel these updates were in fact necessary - I don't think that the way it was done was exemplary in any way... Pretty much each and every point in my email is based on things that I felt went wrong with how we handled the short array syntax RFC: - There wasn't sufficient time, or nearly any time at all - between when Brian pulled it off the attic, and when a vote was called. If my proposal is accepted, there'll have to be at least two weeks between when a clearly marked [RFC] email hits internals@, and when a vote is called. - There wasn't a clearly marked, separate [VOTE] email. - There wasn't a clear or easy way of voting. - No voting period was announced, instead, people were told to stop mess around and go vote. - The author of the RFC wasn't actively involved in the whole process (as far as I could tell); There was no official replacement proposer. I just want to make sure we're on the same page. If you feel that the array syntax RFC was 'done right' then we have a bit of a gap :) In my opinion, given the lacking process, the short array syntax RFC needs to be redone. I'd still like to hear from others what they think about my proposal. I'd like to update the Release Process RFC with these suggestions if people like them. Zeev -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] RE: Voting Process (was: [PHP-DEV] Re: Voting does not belong on the wiki! (Was: [PHP-DEV] 5.4 moving forward))
For those of you who lost these proposals in the flood of RFC related emails of recent days, here they are again: --- First, we need to make sure that the RFC is properly evaluated by the members of internals@, and that there's enough time for the RFC to be discussed here on the list. As Philip pointed out - an RFC is request for comments, not a request for a vote. This list isn't supposed to become some sort of a bureaucratic voting body, but where new ideas are discussed, refined, and eventually - accepted or rejected. I realize that some here are worried that discussions can be endless, but we shouldn't go for the other extreme of having no discussion. For this reason, I propose the following: - There'd be a minimum amount of time between when an RFC is brought up on this list and when it's voted on (say 2wks). The effective date will not be when the RFC was published on wiki.php.net/rfc - but when it was announced on internals@, by the author, with the intention of voting on it. It doesn't matter if the RFC was up there for 2yrs, or discussed 20 times in the past - if the intention is to go for a vote, there needs to be time for a healthy discussion, as opposed to just yes/no. This will also allow for people who are attending conferences, are on vacations, etc. - not to miss an entire discussion/vote. - The announcement will be done in a way that's easy to flag follow, e.g. - by [RFC] in the subject line followed by the title of the RFC. Again, the effective date will start from the time this email is sent to the list, not any other time. - Eventually, it'll be up to the author to move ahead and call a vote on the RFC. That means that if the author feels that there's still healthy discussion going on, he can decide not to move ahead to request a vote after 2wks, but after 3 or 4wks. On the other hand, if he feels that the discussion is being derailed - he can always move ahead to a vote as long as the minimum discussion time elapsed. - In my opinion, only RFCs with active proposers should be discussed. If the proposer of an RFC is no longer leading the effort to get this RFC accepted - it should either find a new proposer, or it should be abandoned. Secondly - the announcement of the vote - I very much agree with Derick that having someone announce a vote in a thread of 50 messages (or even 10) messages is impractical. It needs to be a separate thread, and it has to be clearly marked - a simple subject prefix like [VOTE] followed by the title of the RFC should do. Thirdly, there's the voting mechanism itself. The voting experience has to be nicer than editing a wiki page, I think we all agree about that... The plugin Stas installed gets us something better than that, but ideally, if we could provide single-click URLs in the [VOTE] email itself for voting yay or nay that would be great. Last, we need a predefined time for voting. It too has to be sufficiently long so that everyone has a chance to cast their votes, and on the other end shouldn't be endless. I think the 1wk should do. If there's anybody who feels that the minimum 3wks period is too slow, it isn't. Any mistake we make can take a decade to fix, because downwards compatibility is such an important factor in PHP's design goals. Taking a bit of time to discuss the merits and contents of each RFC is well worth it, especially if we have rules and predefined schedules - so that discussions can't drag forever. Zeev -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: Voting Process (was: [PHP-DEV] Re: Voting does not belong on the wiki! (Was: [PHP-DEV] 5.4 moving forward))
Hi! I'd still like to hear from others what they think about my proposal. I'd like to update the Release Process RFC with these suggestions if people like them. I think these voting process additions totally make sense. But I am not sure it makes sense to put everything in one release RFC. The reason for that is that we don't want to endlessly amend and improve the RFC without having it actually agreed upon, I would rather prefer to agree on what we agree, have it as base for the future and then add other stuff. I've noticed a tendency on the list to lose the major goal behind endless amendments and tweaks and not doing what we agree on because we disagree on some minor detail. So maybe it would make sense to have release RFC separate (without spelling out the voting process there) and voting RFC separate which would define the voting process? -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] RE: Voting Process (was: [PHP-DEV] Re: Voting does not belong on the wiki! (Was: [PHP-DEV] 5.4 moving forward))
I'm fine if the entire 'Feature selection and development' part goes out of the RFC, but if there's any reference to how features are determined, we'd better get it right. Making changes once we've approved this RFC is going to be much tougher. This is big stuff - it's no coincidence we didn't have such guidelines for almost 15 years. Honestly there are other parts about the voting process that are much hotter potatoes than the points I brought up - such as who gets to vote, is 50%+1 enough or do we need stronger majorities for substantial language changes (67%/75%), can someone who failed passing an RFC just put it up for another vote right away or is there some sort of a cool-off period, etc. etc. I think all of these need to be answered before we let this RFC govern how we do feature definition. Zeev -Original Message- From: Stas Malyshev [mailto:smalys...@sugarcrm.com] Sent: Sunday, June 05, 2011 11:17 PM To: Zeev Suraski Cc: Pierre Joye; PHP Internals Subject: Re: Voting Process (was: [PHP-DEV] Re: Voting does not belong on the wiki! (Was: [PHP-DEV] 5.4 moving forward)) Hi! I'd still like to hear from others what they think about my proposal. I'd like to update the Release Process RFC with these suggestions if people like them. I think these voting process additions totally make sense. But I am not sure it makes sense to put everything in one release RFC. The reason for that is that we don't want to endlessly amend and improve the RFC without having it actually agreed upon, I would rather prefer to agree on what we agree, have it as base for the future and then add other stuff. I've noticed a tendency on the list to lose the major goal behind endless amendments and tweaks and not doing what we agree on because we disagree on some minor detail. So maybe it would make sense to have release RFC separate (without spelling out the voting process there) and voting RFC separate which would define the voting process? -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Voting does not belong on the wiki! (Was: [PHP-DEV] 5.4 moving forward)
On 2011-06-05, Pierre Joye pierre@gmail.com wrote: On Sun, Jun 5, 2011 at 5:52 PM, Philip Olson phi...@roshambo.org wrote: I'd to say that I'm very happy to finally see such discussions happening, let sort the base (99% is done by our existing RFC about release process, let adopt it already!) and move on with 5.4. This is a prime example of what we're talking about. Several have expressed a desire to follow an Ubuntu style of branching instead of the style proposed in said RFC. This is a core issue, so the RFC is certainly not ready to adopt. So does this require a new RFC, or do the RFC proposers feel this is a key concept? As I stated before, there is a RFC with a fair amount of developers involved. Some of the supporters of the Ubuntu TLS model already changed their mind (as it clearly does not work for php, random features being TLS just because of the timing makes no sense). If you think a RFC is not ready, not desired, not good enough or whatever other reason motivates you, vote against and propose something else. But you can even say no and propose nothing afterwards. I agree. People should stick to the RFC system to hve a documented way of saying what they like and what not. If the RFC writers want to adopt a change that's their things. So far there is no reason to change it. As of this specific RFC, it is actually a very good one, it is not perfect and will need adjustement in the coming years, that's a damned sure thing. But we can not argue forever only because a minority thinks we should argue endlessly or change nothing. Yes. The Release RFC is nothing that needs Backward compatbility. We should vote on the general direction instead of fighting over a minor details and getting nothing done. Details can be modified with later RFCs. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: Voting Process (was: [PHP-DEV] Re: Voting does not belong on the wiki! (Was: [PHP-DEV] 5.4 moving forward))
On Sun, Jun 5, 2011 at 10:55 PM, Zeev Suraski z...@zend.com wrote: I'm fine if the entire 'Feature selection and development' part goes out of the RFC, but if there's any reference to how features are determined, we'd better get it right. Getting it totally out makes little sense as it brings us to the point where we have no idea how we decide what gets in or not, the RMs, etc. Making changes once we've approved this RFC is going to be much tougher. This is big stuff - it's no coincidence we didn't have such guidelines for almost 15 years. That was not the reason, the lack of will to define such processes was the reason despite the numerous requests to have one from in and outside the core team. Honestly there are other parts about the voting process that are much hotter potatoes than the points I brought up - such as who gets to vote, is 50%+1 enough or do we need stronger majorities for substantial language changes (67%/75%), can someone who failed passing an RFC just put it up for another vote right away or is there some sort of a cool-off period, etc. etc. I think all of these need to be answered before we let this RFC govern how we do feature definition. I'd to go with a 60% for language syntax, 50+1 for new exts or sapis. Other question is who can vote. For one, I like to have external people being able to vote, like frameworks/apps lead developers as well as @php.net in general (docs people at the same level than core devs, no diff). However I'd to say as well as I have no issue at all to define the basis of the voting system in it and add a note that it may be tuned later once we have more experiences. That's perfectly fine, nobody expects us to be perfect with the 1st shot. Cheers, -- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: Voting Process (was: [PHP-DEV] Re: Voting does not belong on the wiki! (Was: [PHP-DEV] 5.4 moving forward))
hi Zeev, On Sun, Jun 5, 2011 at 10:05 PM, Zeev Suraski z...@zend.com wrote: Pierre, I'm happy that we agree pretty much completely about the clarifications updates needed for the RFC. Same here :) I do however want to point out that the problematic way the short array syntax RFC was executed was the key reason that made me feel these updates were in fact necessary - I don't think that the way it was done was exemplary in any way... Well, it was done in a way without having an official way, so no, it was not perfect. Pretty much each and every point in my email is based on things that I felt went wrong with how we handled the short array syntax RFC: - There wasn't sufficient time, or nearly any time at all - between when Brian pulled it off the attic, and when a vote was called. If my proposal is accepted, there'll have to be at least two weeks between when a clearly marked [RFC] email hits internals@, and when a vote is called. - There wasn't a clearly marked, separate [VOTE] email. - There wasn't a clear or easy way of voting. - No voting period was announced, instead, people were told to stop mess around and go vote. - The author of the RFC wasn't actively involved in the whole process (as far as I could tell); There was no official replacement proposer. I just want to make sure we're on the same page. If you feel that the array syntax RFC was 'done right' then we have a bit of a gap :) In my opinion, given the lacking process, the short array syntax RFC needs to be redone. As I agree on everything you wrote here, I don't feel like we need to redo it. The votes result is pretty clear, despite 2-3 people not willing to vote for whatever reasons: https://wiki.php.net/rfc/shortsyntaxforarrays/vote All votes happened again after the alternatives have been proposed or discussed. One would have voted against this RFC if any of the alternatives was better. Anyway, if enough people thinks they want to re do it (3rd time IIRC), so be it. I'd still like to hear from others what they think about my proposal. I'd like to update the Release Process RFC with these suggestions if people like them. I'm all for theses changes and updates. Cheers, -- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] 5.4 moving forward
Hi! On 2011-06-05, Pierre Joyepierre@gmail.com wrote: On Sun, Jun 5, 2011 at 5:52 PM, Philip Olsonphi...@roshambo.org wrote: I'd to say that I'm very happy to finally see such discussions happening, let sort the base (99% is done by our existing RFC about release process, let adopt it already!) and move on with 5.4. This is a prime example of what we're talking about. Several have expressed a desire to follow an Ubuntu style of branching instead of the style proposed in said RFC. This is a core issue, so the RFC is certainly not ready to adopt. So does this require a new RFC, or do the RFC proposers feel this is a key concept? I think that this RFC does not contain Ubuntu-style LTS and it doesn't look like it's author(s) support it, so it should be some different point, which may be RFCed and voted on if we see substantial support for it. Speaking of which, I personally don't understand how LTS thing would work in PHP. Does it mean we'd decide out of the blue that some version would have extended support, upfront? Like, say, we now say 5.5 would have extended support? Why would we want to do this, how would we know it? E.g., I understand if we had an option of extending support for some version post-factum, e.g., somewhere in 2015 we'd say 5.4 is so damn good and 5.5 has so many substantial changes that now we want 5.4 support to be extended another couple of years, and we feel we have people that are willing to do it. We could then talk on it and decide it, nothing prevents it. But as I understand LTS model means we'd have to decide it now, in 2011, and I don't see how it works. Could some of the proponents on this model explain it? -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] RE: Voting Process (was: [PHP-DEV] Re: Voting does not belong on the wiki! (Was: [PHP-DEV] 5.4 moving forward))
[resending as the list appears to reject bit.ly URLs] As I agree on everything you wrote here, I don't feel like we need to redo it. The votes result is pretty clear, despite 2-3 people not willing to vote for whatever reasons: https://wiki.php.net/rfc/shortsyntaxforarrays/vote Take a look at http://english.ahram.org.eg/NewsContent/1/5/1712/Egypt/Egypt-Elections-/Mubarak-Despite-some-irregularities-elections-were.aspx . Spotting any resemblance? Look where he's at now :) Major parts in the process weren't executed properly (I've spelled them out so I won't repeat them). It's quite possible that if they were executed properly, we'd have different results. Perhaps not, maybe even probably not, but unless we do it right we'll never know. Also, I suspect that you'd find that there are more than just a couple of people who 'refused to vote'. I'm betting that there are plenty of people who had no idea a vote was going on, and plenty more that weren't entirely clear on what exactly it is they're voting on - with all the discussion that happened on internals@ spreading in half a dozen different directions. Zeev -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: Voting Process (was: [PHP-DEV] Re: Voting does not belong on the wiki! (Was: [PHP-DEV] 5.4 moving forward))
take #4.. Hmmm, not sure I like the comparison (with Egypt). Major parts in the process weren't executed properly (I've spelled them out so I won't repeat them). It's quite possible that if they were executed properly, we'd have different results. Perhaps not, maybe even probably not, but unless we do it right we'll never know. Are you saying that most people having voted +1 once, then a 2nd time +1 and finally a 3rd time (editing the votes to put it under the right syntax), would suddenly be totally against it? Also, I suspect that you'd find that there are more than just a couple of people who 'refused to vote'. I'm betting that there are plenty of people who had no idea a vote was going on, and plenty more that weren't entirely clear on what exactly it is they're voting on - with all the discussion that happened on internals@ spreading in half a dozen different directions. Given the active people, both in discussions and developments, I keep my estimation to 2-3 refusing to vote and the rest not giving it enough importance or does not care at all. In any case, if you feel like we have to re vote, and many do as well, then so be it. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Voting does not belong on the wiki! (Was: [PHP-DEV] 5.4 moving forward)
On Sat, Jun 4, 2011 at 5:46 AM, Stas Malyshev smalys...@sugarcrm.com wrote: [VOTE] is a good idea, let's make it [VOTE]. There is no plugin used for it yet, and that's my problem with it. Well, votes aren't announced yet either :) I'll try to get it set up ASAP and see how it works, before announcing the vote. It looks good in description at least. Please keep them in the wiki as we planed to do. THere are plugins and it is very easy to manage, allows per section voting etc. -- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Voting does not belong on the wiki! (Was: [PHP-DEV] 5.4 moving forward)
On Jun 4, 2011, at 3:07 AM, Pierre Joye wrote: On Sat, Jun 4, 2011 at 5:46 AM, Stas Malyshev smalys...@sugarcrm.com wrote: [VOTE] is a good idea, let's make it [VOTE]. There is no plugin used for it yet, and that's my problem with it. Well, votes aren't announced yet either :) I'll try to get it set up ASAP and see how it works, before announcing the vote. It looks good in description at least. Please keep them in the wiki as we planed to do. THere are plugins and it is very easy to manage, allows per section voting etc. I'm hopeful people will continue to understand the RFC definition: - RFC: Request For Comments And while doing so, not revert to a vote (RFV?) simply because discussing a topic can get messy. Voting has clear winners and losers with potential loss for improvements. That and you must then worry about who can and cannot vote (i.e., non-inclusive community). It's rare that we've required a formal vote, so I fear we will now implement voting at inappropriate times rather than allow a consensus to be reached. Also, people should be given a reasonable opportunity to offer an alternative RFC. Regards, Philip -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Re: Voting does not belong on the wiki! (Was: [PHP-DEV] 5.4 moving forward)
Speaking generally, consensus is a dangerous and impossible standard. Few things can cripple progress like waiting for consensus. Voting may be one good way to move things forward without deadlocking forever. I agree though that without clear rules for how the process should work, voting is also chaotic. (Who can call for a vote? How? When is it final? Who can vote? How do they vote? How much is each vote worth? Is a simple majority or super majority needed?) John Crenshaw Priacta, Inc. -Original Message- From: Philip Olson [mailto:phi...@roshambo.org] Sent: Saturday, June 04, 2011 9:30 AM To: Pierre Joye Cc: Stas Malyshev; Derick Rethans; PHP Internals Subject: Re: [PHP-DEV] Re: Voting does not belong on the wiki! (Was: [PHP-DEV] 5.4 moving forward) On Jun 4, 2011, at 3:07 AM, Pierre Joye wrote: On Sat, Jun 4, 2011 at 5:46 AM, Stas Malyshev smalys...@sugarcrm.com wrote: [VOTE] is a good idea, let's make it [VOTE]. There is no plugin used for it yet, and that's my problem with it. Well, votes aren't announced yet either :) I'll try to get it set up ASAP and see how it works, before announcing the vote. It looks good in description at least. Please keep them in the wiki as we planed to do. THere are plugins and it is very easy to manage, allows per section voting etc. I'm hopeful people will continue to understand the RFC definition: - RFC: Request For Comments And while doing so, not revert to a vote (RFV?) simply because discussing a topic can get messy. Voting has clear winners and losers with potential loss for improvements. That and you must then worry about who can and cannot vote (i.e., non-inclusive community). It's rare that we've required a formal vote, so I fear we will now implement voting at inappropriate times rather than allow a consensus to be reached. Also, people should be given a reasonable opportunity to offer an alternative RFC. Regards, Philip -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Voting does not belong on the wiki! (Was: [PHP-DEV] 5.4 moving forward)
hi Philip, On Sat, Jun 4, 2011 at 3:29 PM, Philip Olson phi...@roshambo.org wrote: - RFC: Request For Comments Thanks for the reminder. But RFC got approved at some point as well. See the numerous W3C RFCs for some known examples. And while doing so, not revert to a vote (RFV?) simply because discussing a topic can get messy. What got messy? That instead of simply rejecting the RFC instead of constantly adding new ideas to the stack. It is a perfectly valid flow to block a RFC because it is considered as not well designed, not desired or simple not fully compliant. It happened many times in php in the past and in other projects as well. Voting has clear winners and losers with potential loss for improvements. That and you must then worry about who can and cannot vote (i.e., non-inclusive community). It's rare that we've required a formal vote, so I fear we will now implement voting at inappropriate times rather than allow a consensus to be reached. I'm sorry to not be powerful enough to achieve my ultimate goal, have the most open processes and decissions in the OSS world within PHP. That is, to include the communities in the decision processes and not only to propose things. Now you can keep arguing that voting is pointless, unfair, that consensus can be reached easily, etc. etc. What we see is a total different picture which is more related to dictatorial decisions or puchists. None of these ways are good. Cheers, -- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Voting does not belong on the wiki! (Was: [PHP-DEV] 5.4 moving forward)
Hi! Please keep them in the wiki as we planed to do. THere are plugins and it is very easy to manage, allows per section voting etc. I've installed voting plugin, see description here: http://www.dokuwiki.org/plugin:doodle2 and example how it looks here at the end (login required to vote): https://wiki.php.net/playground/playground I think it'd work. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Voting does not belong on the wiki! (Was: [PHP-DEV] 5.4 moving forward)
right, that's the one I was willing to install as well, great that you did it! Thanks :) On Sat, Jun 4, 2011 at 7:58 PM, Stas Malyshev smalys...@sugarcrm.com wrote: Hi! Please keep them in the wiki as we planed to do. THere are plugins and it is very easy to manage, allows per section voting etc. I've installed voting plugin, see description here: http://www.dokuwiki.org/plugin:doodle2 and example how it looks here at the end (login required to vote): https://wiki.php.net/playground/playground I think it'd work. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Voting does not belong on the wiki! (Was: [PHP-DEV] 5.4 moving forward)
On Sat, Jun 4, 2011 at 19:58, Stas Malyshev smalys...@sugarcrm.com wrote: Hi! Please keep them in the wiki as we planed to do. THere are plugins and it is very easy to manage, allows per section voting etc. I've installed voting plugin, see description here: http://www.dokuwiki.org/plugin:doodle2 and example how it looks here at the end (login required to vote): https://wiki.php.net/playground/playground I think it'd work. How does it work? Do you need write permission to the page it is located on, or is it enough to have login? How do you differentiate between 'core' and 'community' voting? (or is that maybe not needed?) -Hannes -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Voting does not belong on the wiki! (Was: [PHP-DEV] 5.4 moving forward)
On Thu, 2 Jun 2011, Stas Malyshev wrote: I'd like to set up a vote for the undecided TODO features on wiki.php.net, anybody could help me with setting up the voting module there if there's such thing on the wiki? Or set me up with the access to wiki machine and I'll install it :) Voting on the wiki? Yuck. If you want participation, do it here on the mailinglist and store the record in the wiki. If all votes are showing up just in the wiki then there is no exposure on the list and things are easy to miss (especially with the huge amount of noise that's already on the list). Derick -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Voting does not belong on the wiki! (Was: [PHP-DEV] 5.4 moving forward)
2011/6/3 Derick Rethans der...@php.net: On Thu, 2 Jun 2011, Stas Malyshev wrote: I'd like to set up a vote for the undecided TODO features on wiki.php.net, anybody could help me with setting up the voting module there if there's such thing on the wiki? Or set me up with the access to wiki machine and I'll install it :) Voting on the wiki? Yuck. If you want participation, do it here on the mailinglist and store the record in the wiki. If all votes are showing up just in the wiki then there is no exposure on the list and things are easy to miss (especially with the huge amount of noise that's already on the list). Why not just to separate voting from participation? I doubt there is somebody that counts all these +1 in the list and tracks progress. I suggest keep voting only in wiki and discussions in ML. Don't have consice opinion yet? Participate ML. Got opinion? Go and vote in the wiki, no need to +1/-1 in the list, it's already too much noise here. Derick -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- Regards, Shein Alexey -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: Voting does not belong on the wiki! (Was: [PHP-DEV] 5.4 moving forward)
Hi! Voting on the wiki? Yuck. If you want participation, do it here on the mailinglist and store the record in the wiki. If all votes are showing Voting on ML is messy and means somebody needs to read every message on the list and look for votes, however long, tedious and offtopic the discussion gets. Voting with, well, voting application is clean, automatic and efficient. I don't understand why we should use medium that is unfit for the purpose instead of using applications specifically designed for doing what we try to do. up just in the wiki then there is no exposure on the list and things are easy to miss (especially with the huge amount of noise that's already on the list). There will be exposure to the list, with list of topics and explanations. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Voting does not belong on the wiki! (Was: [PHP-DEV] 5.4 moving forward)
Why doesnt voting happen using a poll/voting engine. Written in (gasp) PHP! (although soon PJSON) On Jun 3, 2011, at 1:03 AM, Stas Malyshev smalys...@sugarcrm.com wrote: Hi! Voting on the wiki? Yuck. If you want participation, do it here on the mailinglist and store the record in the wiki. If all votes are showing Voting on ML is messy and means somebody needs to read every message on the list and look for votes, however long, tedious and offtopic the discussion gets. Voting with, well, voting application is clean, automatic and efficient. I don't understand why we should use medium that is unfit for the purpose instead of using applications specifically designed for doing what we try to do. up just in the wiki then there is no exposure on the list and things are easy to miss (especially with the huge amount of noise that's already on the list). There will be exposure to the list, with list of topics and explanations. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: Voting does not belong on the wiki! (Was: [PHP-DEV] 5.4 moving forward)
On Fri, 3 Jun 2011, Stas Malyshev wrote: Voting on the wiki? Yuck. If you want participation, do it here on the mailinglist and store the record in the wiki. If all votes are showing Voting on ML is messy and means somebody needs to read every message on the list and look for votes, however long, tedious and offtopic the discussion gets. Voting with, well, voting application is clean, automatic and efficient. I don't understand why we should use medium that is unfit for the purpose instead of using applications specifically designed for doing what we try to do. Yes, it's messy on ML. My points where: - a call to vote is easily drowned out on the ML with all the noise - editting votes on a wiki can too easily be manipulated (I could just change your votes, and there would be no trail). And IMO, those two things should be sorted out before we decide to do votes by editting some page on some wiki. Derick -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Voting does not belong on the wiki! (Was: [PHP-DEV] 5.4 moving forward)
Have you guys considered doodle.com? I think you are all stressing way too much over the voting process. When a vote is closed you can then transfer the decision to the RFC. Drak On 3 June 2011 14:12, Pierre Joye pierre@gmail.com wrote: On Fri, Jun 3, 2011 at 10:22 AM, Derick Rethans der...@php.net wrote: On Fri, 3 Jun 2011, Stas Malyshev wrote: Voting on the wiki? Yuck. If you want participation, do it here on the mailinglist and store the record in the wiki. If all votes are showing Voting on ML is messy and means somebody needs to read every message on the list and look for votes, however long, tedious and offtopic the discussion gets. Voting with, well, voting application is clean, automatic and efficient. I don't understand why we should use medium that is unfit for the purpose instead of using applications specifically designed for doing what we try to do. Yes, it's messy on ML. My points where: - a call to vote is easily drowned out on the ML with all the noise - editting votes on a wiki can too easily be manipulated (I could just change your votes, and there would be no trail). There is a log and we know who did edit what. Basic trust is required anyway and if such tricks happen, really, I do not know what to think about the person doing them (well I do, but that's not the place to say it). A plugin will be installed to ease the process, login, vote. You won't be able to add/edit other votes. About when a vote happens and how to inform the devs, I do not see other solutions than getting the devs to read the discussions on the MLs. If some can't stand the heat, then we can't do much for them anyway, Cheers, -- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: Voting does not belong on the wiki! (Was: [PHP-DEV] 5.4 moving forward)
Hi! - a call to vote is easily drowned out on the ML with all the noise I read the same ML as you do :) Using threaded email client it is very easy to separate new threads and see calls for votes. Also, voting on ML does not solve the drowning out problem, it makes it worse as about 80% of the people in given vote in a given moment can't say what they are/supposed to be voting for, is discussion still ongoing and what's the consensus, if any. - editting votes on a wiki can too easily be manipulated (I could just change your votes, and there would be no trail). Votes are public, if you see somebody edited it you'd notice. As editing could be done only by admins (if I understand correctly, same guys having root on pretty much all PHP infrastructure) if a plugin is used (see below) I don't think it's a big concern. And IMO, those two things should be sorted out before we decide to do votes by editting some page on some wiki. docuwiki has voting plugins for that purpose, editing some page is not the only way. For example: http://www.dokuwiki.org/plugin:doodle2 -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Voting does not belong on the wiki! (Was: [PHP-DEV] 5.4 moving forward)
hi Derick, On Fri, Jun 3, 2011 at 9:45 AM, Derick Rethans der...@php.net wrote: On Thu, 2 Jun 2011, Stas Malyshev wrote: I'd like to set up a vote for the undecided TODO features on wiki.php.net, anybody could help me with setting up the voting module there if there's such thing on the wiki? Or set me up with the access to wiki machine and I'll install it :) Voting on the wiki? Yuck. If you want participation, do it here on the mailinglist and store the record in the wiki. If all votes are showing up just in the wiki then there is no exposure on the list and things are easy to miss (especially with the huge amount of noise that's already on the list). Please re consider your opinion like noises on the list and other similar statements, thanks. As of the votes in the wiki, it is perfectly fine and valid, easy to manage and open. Much more easier than counting random votes in the ML, especially when discussions are split in many threads. The discussions and related activities do happen on the list and that's a good thing. -- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: Voting does not belong on the wiki! (Was: [PHP-DEV] 5.4 moving forward)
On Fri, 3 Jun 2011, Stas Malyshev wrote: - a call to vote is easily drowned out on the ML with all the noise I read the same ML as you do :) Using threaded email client it is very easy to separate new threads and see calls for votes. That is subjective. And even with a threaded client, if there are 80+ new messages then the call for vote is drowned out. *Requiring* something like [VOTE] in the subject helps, as then you can set-up a filter. And if it's a requirement, every call without [VOTE] in the subject is invalid. (Easy to fix if somebody forgot it as well). It would expose this kind of thing. Also, voting on ML does not solve the drowning out problem, it makes it worse as about 80% of the people in given vote in a given moment can't say what they are/supposed to be voting for, is discussion still ongoing and what's the consensus, if any. I didn't disagree with this. - editting votes on a wiki can too easily be manipulated (I could just change your votes, and there would be no trail). Votes are public, if you see somebody edited it you'd notice. As editing could be done only by admins (if I understand correctly, same guys having root on pretty much all PHP infrastructure) if a plugin is used (see below) I don't think it's a big concern. And IMO, those two things should be sorted out before we decide to do votes by editting some page on some wiki. docuwiki has voting plugins for that purpose, editing some page is not the only way. For example: http://www.dokuwiki.org/plugin:doodle2 There is no plugin used for it yet, and that's my problem with it. Derick -- http://derickrethans.nl | http://xdebug.org Like Xdebug? Consider a donation: http://xdebug.org/donate.php twitter: @derickr and @xdebug -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Voting does not belong on the wiki! (Was: [PHP-DEV] 5.4 moving forward)
Martin Scotta On Fri, Jun 3, 2011 at 5:16 AM, Pierre Joye pierre@gmail.com wrote: hi Derick, On Fri, Jun 3, 2011 at 9:45 AM, Derick Rethans der...@php.net wrote: On Thu, 2 Jun 2011, Stas Malyshev wrote: I'd like to set up a vote for the undecided TODO features on wiki.php.net, anybody could help me with setting up the voting module there if there's such thing on the wiki? Or set me up with the access to wiki machine and I'll install it :) Voting on the wiki? Yuck. If you want participation, do it here on the mailinglist and store the record in the wiki. If all votes are showing up just in the wiki then there is no exposure on the list and things are easy to miss (especially with the huge amount of noise that's already on the list). Please re consider your opinion like noises on the list and other similar statements, thanks. As of the votes in the wiki, it is perfectly fine and valid, easy to manage and open. Much more easier than counting random votes in the ML, especially when discussions are split in many threads. The discussions and related activities do happen on the list and that's a good thing. Yes, but only who has wiki karma are allowed to vote. -- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Voting does not belong on the wiki! (Was: [PHP-DEV] 5.4 moving forward)
How about a separate email topic dedicated to voting?, that would reduce the signal to noise ratio for votes (and increase it for opinions). Regards, David On Fri, Jun 3, 2011 at 10:25 AM, Martin Scotta martinsco...@gmail.comwrote: Martin Scotta On Fri, Jun 3, 2011 at 5:16 AM, Pierre Joye pierre@gmail.com wrote: hi Derick, On Fri, Jun 3, 2011 at 9:45 AM, Derick Rethans der...@php.net wrote: On Thu, 2 Jun 2011, Stas Malyshev wrote: I'd like to set up a vote for the undecided TODO features on wiki.php.net, anybody could help me with setting up the voting module there if there's such thing on the wiki? Or set me up with the access to wiki machine and I'll install it :) Voting on the wiki? Yuck. If you want participation, do it here on the mailinglist and store the record in the wiki. If all votes are showing up just in the wiki then there is no exposure on the list and things are easy to miss (especially with the huge amount of noise that's already on the list). Please re consider your opinion like noises on the list and other similar statements, thanks. As of the votes in the wiki, it is perfectly fine and valid, easy to manage and open. Much more easier than counting random votes in the ML, especially when discussions are split in many threads. The discussions and related activities do happen on the list and that's a good thing. Yes, but only who has wiki karma are allowed to vote. -- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Voting does not belong on the wiki! (Was: [PHP-DEV] 5.4 moving forward)
Hi! That is subjective. And even with a threaded client, if there are 80+ new messages then the call for vote is drowned out. *Requiring* There was never 80+ new messages on different topics on the list. There are 3-4 topics max, if you not count commit messages. Each of them can contain dozens of messages, but those can be easily grouped. something like [VOTE] in the subject helps, as then you can set-up a [VOTE] is a good idea, let's make it [VOTE]. There is no plugin used for it yet, and that's my problem with it. Well, votes aren't announced yet either :) I'll try to get it set up ASAP and see how it works, before announcing the vote. It looks good in description at least. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] 5.4 moving forward
Hi! We're having pretty lively discussion on the list, twitter and other places, but let's not forget the big goal of 5.4 :) 1. First of all, the official business. Any objections to the RMs for 5.4 being: Stas Malyshev (stas) David Soria Parra (dsp) If not, we'll be the 5.4 RM team. 2. Candidates for 5.4: please review this list: https://wiki.php.net/todo/php54 I'd like to set up a vote for the undecided TODO features on wiki.php.net, anybody could help me with setting up the voting module there if there's such thing on the wiki? Or set me up with the access to wiki machine and I'll install it :) Some of the items are already being discussed, but I'll prepare some kind of official ballot and send to the list soon so we'd have common point. I think it makes sense to have the following limits of the features: a. It should be either obvious how to do it (example: adding E_STRICT to E_ALL), or have full design working patch w/tests or somebody has to commit to doing it within roughly a month term. b. I think we should leave out any big things now, e.g.: annotations - sorry, I know there are many people supporting it, but right now it doesn't seem to be a consensus on how to do it, so I'd rather target 5.5 for it, which if we can make this release go smoothly won't have to be too far out. 3. I'd like to create first alpha sometime next week, if somebody has anything that's not in and wants it in please talk to me. This alpha should in no way be seen as anything stable or final, but rather as a first step on a road to 5.4. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] 5.4 moving forward
hi, I have no objection as long as the RFC for the release process is adopted before we do any 5.4 releases, as stated earlier, this is the only way to put ourself on the safe side. Cheers, On Thu, Jun 2, 2011 at 10:24 PM, Stas Malyshev smalys...@sugarcrm.com wrote: Hi! We're having pretty lively discussion on the list, twitter and other places, but let's not forget the big goal of 5.4 :) 1. First of all, the official business. Any objections to the RMs for 5.4 being: Stas Malyshev (stas) David Soria Parra (dsp) If not, we'll be the 5.4 RM team. 2. Candidates for 5.4: please review this list: https://wiki.php.net/todo/php54 I'd like to set up a vote for the undecided TODO features on wiki.php.net, anybody could help me with setting up the voting module there if there's such thing on the wiki? Or set me up with the access to wiki machine and I'll install it :) Some of the items are already being discussed, but I'll prepare some kind of official ballot and send to the list soon so we'd have common point. I think it makes sense to have the following limits of the features: a. It should be either obvious how to do it (example: adding E_STRICT to E_ALL), or have full design working patch w/tests or somebody has to commit to doing it within roughly a month term. b. I think we should leave out any big things now, e.g.: annotations - sorry, I know there are many people supporting it, but right now it doesn't seem to be a consensus on how to do it, so I'd rather target 5.5 for it, which if we can make this release go smoothly won't have to be too far out. 3. I'd like to create first alpha sometime next week, if somebody has anything that's not in and wants it in please talk to me. This alpha should in no way be seen as anything stable or final, but rather as a first step on a road to 5.4. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] 5.4 moving forward
Sounds fine to me. On Thu, Jun 2, 2011 at 10:24 PM, Stas Malyshev smalys...@sugarcrm.com wrote: Hi! We're having pretty lively discussion on the list, twitter and other places, but let's not forget the big goal of 5.4 :) 1. First of all, the official business. Any objections to the RMs for 5.4 being: Stas Malyshev (stas) David Soria Parra (dsp) If not, we'll be the 5.4 RM team. 2. Candidates for 5.4: please review this list: https://wiki.php.net/todo/php54 I'd like to set up a vote for the undecided TODO features on wiki.php.net, anybody could help me with setting up the voting module there if there's such thing on the wiki? Or set me up with the access to wiki machine and I'll install it :) Some of the items are already being discussed, but I'll prepare some kind of official ballot and send to the list soon so we'd have common point. I think it makes sense to have the following limits of the features: a. It should be either obvious how to do it (example: adding E_STRICT to E_ALL), or have full design working patch w/tests or somebody has to commit to doing it within roughly a month term. b. I think we should leave out any big things now, e.g.: annotations - sorry, I know there are many people supporting it, but right now it doesn't seem to be a consensus on how to do it, so I'd rather target 5.5 for it, which if we can make this release go smoothly won't have to be too far out. 3. I'd like to create first alpha sometime next week, if somebody has anything that's not in and wants it in please talk to me. This alpha should in no way be seen as anything stable or final, but rather as a first step on a road to 5.4. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] 5.4 moving forward
On Thu, Jun 2, 2011 at 22:24, Stas Malyshev smalys...@sugarcrm.com wrote: I'd like to set up a vote for the undecided TODO features on wiki.php.net, anybody could help me with setting up the voting module there if there's such thing on the wiki? Or set me up with the access to wiki machine and I'll install it :) You are in general much more likely to get serious reply on this sort of things on the.. mailinglists dedicated for it (php-webmaster@ / systems@). There is just way to much trolling going on on this list for us to be able to read all posts. The wiki code is in svn, so you should be able to commit whatever plugin you need. If you need access to the actual box, ask the technical contact listed on https://wiki.php.net/systems/rl, or systems@ for any other questions. Some of the items are already being discussed, but I'll prepare some kind of official ballot and send to the list soon so we'd have common point. There are still leftovers from the scalar type hint in svn, check zend_do_receive_arg() and zend_do_perform_implementation_check() for example. Please verify you reverted it properly, as these half-reverting is causing segfaults whereas syntax error would be expected. -Hannes -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
