[PHP-DEV] Re: voting without vcs accounts
On Mon, Apr 16, 2012 at 10:14 AM, Ferenc Kovacs tyr...@gmail.com wrote: Hi, I sent an email last year about this issue, but it got sidetracked (partly it was my fault): http://www.mail-archive.com/internals@lists.php.net/msg54267.html So this time, I would like focusing only on the following: 1. What are the requirements for getting voting rights in the wiki without having a vcs/master account? - The voting RFC states: - Representatives from the PHP community, that will be chosen by those with php.net SVN accounts - Lead developers of PHP based projects (frameworks, cms, tools, etc.) - regular participant of internals discussions 2. What are the necessary steps from a volunteer to request voting karma? 3. How do we handle the applicants? Who will judge the applications? 4. How can we see the list of the people having voting karma? Currently only the wiki admins can see who are the people with the voting group membership. The wiki is already prepared to support voting without vcs account: there is a voting group, anybody having membership in that group are able to vote ( http://git.php.net/?p=web/wiki.git;a=commit;h=e3b97f03548fab661b5bc2dd66420db1024b1f39 ). My personal opinion would be that we have an application form like we have for the vcs account request, which will send an email to the mailing list, we can discuss here whether we support/approve the applicant or not, and somebody with proper karma can approve/decline the application, which would also trigger an email to the mailing list. -- Ferenc Kovács @Tyr43l - http://tyrael.hu Hi, Seeing the discussion/confusion yesterday I'm bringing this up again, maybe we can get an agreement this time. -- Ferenc Kovács @Tyr43l - http://tyrael.hu
Re: [PHP-DEV] Current Status of O+ on Windows
Did you experiment with any options? Putting the date of your O+ snapshot would also be handy. Latest from here are used: http://windows.php.net/downloads/pecl/snaps/Optimizer/7.0.0-dev/ Dates are included. It would be nice to have it in the report as well, but we always use latest revision. It would however be much easier if there were PECL releases. +1 Dmitry, is there any objection against creating a pecl release? Could you tag the first version? -- Ferenc Kovács @Tyr43l - http://tyrael.hu
RE: [PHP-DEV] Current Status of O+ on Windows
-Original Message- From: Ferenc Kovacs [mailto:tyr...@gmail.com] Sent: Saturday, March 02, 2013 10:15 AM To: Pierre Joye; Dmitry Stogov Cc: Christopher Jones; Matt Ficken; internals@lists.php.net Subject: Re: [PHP-DEV] Current Status of O+ on Windows Did you experiment with any options? Putting the date of your O+ snapshot would also be handy. Latest from here are used: http://windows.php.net/downloads/pecl/snaps/Optimizer/7.0.0-dev/ Dates are included. It would be nice to have it in the report as well, but we always use latest revision. It would however be much easier if there were PECL releases. +1 Dmitry, is there any objection against creating a pecl release? Could you tag the first version? The current vote that's going on right now deals with putting the extension into PHP itself. If that happens (which seems awfully likely at this point), why do we need it in PECL? We'd very much rather invest our very limited cycles into the code itself. We're probably roughly a week away from having builds as a part of the PHP 5.5 snaps. Zeev -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Current Status of O+ on Windows
On Sat, Mar 2, 2013 at 9:39 AM, Zeev Suraski z...@zend.com wrote: -Original Message- From: Ferenc Kovacs [mailto:tyr...@gmail.com] Sent: Saturday, March 02, 2013 10:15 AM To: Pierre Joye; Dmitry Stogov Cc: Christopher Jones; Matt Ficken; internals@lists.php.net Subject: Re: [PHP-DEV] Current Status of O+ on Windows Did you experiment with any options? Putting the date of your O+ snapshot would also be handy. Latest from here are used: http://windows.php.net/downloads/pecl/snaps/Optimizer/7.0.0-dev/ Dates are included. It would be nice to have it in the report as well, but we always use latest revision. It would however be much easier if there were PECL releases. +1 Dmitry, is there any objection against creating a pecl release? Could you tag the first version? The current vote that's going on right now deals with putting the extension into PHP itself. If that happens (which seems awfully likely at this point), why do we need it in PECL? We'd very much rather invest our very limited cycles into the code itself. We're probably roughly a week away from having builds as a part of the PHP 5.5 snaps. Zeev I see. so no O+ for 5.5? having a pecl release would be a small amount of work, which I would glad to help with. -- Ferenc Kovács @Tyr43l - http://tyrael.hu
[PHP-DEV] 回复： [PHP-DEV] Current Status of O+ on Windows
+1 s, Switch to a new opcode cacher is much easier than update PHP, and ZO+ is already compatible with 5.5. we could use ZO+ as soon as possible. -- reeze | reeze.cn 已使用 Sparrow (http://www.sparrowmailapp.com/?sig) 在 2013年3月2日星期六，下午4:43，Ferenc Kovacs 写道： On Sat, Mar 2, 2013 at 9:39 AM, Zeev Suraski z...@zend.com (mailto:z...@zend.com) wrote: -Original Message- From: Ferenc Kovacs [mailto:tyr...@gmail.com] Sent: Saturday, March 02, 2013 10:15 AM To: Pierre Joye; Dmitry Stogov Cc: Christopher Jones; Matt Ficken; internals@lists.php.net (mailto:internals@lists.php.net) Subject: Re: [PHP-DEV] Current Status of O+ on Windows Did you experiment with any options? Putting the date of your O+ snapshot would also be handy. Latest from here are used: http://windows.php.net/downloads/pecl/snaps/Optimizer/7.0.0-dev/ Dates are included. It would be nice to have it in the report as well, but we always use latest revision. It would however be much easier if there were PECL releases. +1 Dmitry, is there any objection against creating a pecl release? Could you tag the first version? The current vote that's going on right now deals with putting the extension into PHP itself. If that happens (which seems awfully likely at this point), why do we need it in PECL? We'd very much rather invest our very limited cycles into the code itself. We're probably roughly a week away from having builds as a part of the PHP 5.5 snaps. Zeev I see. so no O+ for 5.5? having a pecl release would be a small amount of work, which I would glad to help with. -- Ferenc Kovács @Tyr43l - http://tyrael.hu
Re: [PHP-DEV] O+ support for PHP 5.x (Was current Status of O+ on Windows)
On 02/03/13 08:39, Zeev Suraski wrote: The current vote that's going on right now deals with putting the extension into PHP itself. If that happens (which seems awfully likely at this point), why do we need it in PECL? My response to your Q is that there is probably going to be quite a lot of interest in an O+ package that is usable with PHP 5.3 and 5.4. Surely a PECL package will have a quicker uptake terms of getting it out into the wider PHP developers community and into production, especially if the main Linux distros add a precompiled php5-optimizer-plus package (or whatever their naming convention is). Would you see such O+ support for the existing supported versions best done through the PECL route or swept up into a maintenance dot release? Regards Terry
[PHP-DEV] Optimizer+ bugreps
At what point is O+ reporting going to be possible through https://bugs.php.net/ ? I realize that this is a bit of a catch-22, but surely it would be better to allow properly tracked open bug reporting sooner rather later? Regards Terry
Re: [PHP-DEV] Optimizer+ bugreps
Having it in peck right now allows that. But as of now it is not a PHP.net project so it makes little sense to have it listed there. On Mar 2, 2013 10:33 AM, Terry Ellison te...@ellisons.org.uk wrote: At what point is O+ reporting going to be possible through https://bugs.php.net/ ? I realize that this is a bit of a catch-22, but surely it would be better to allow properly tracked open bug reporting sooner rather later? Regards Terry
[PHP-DEV] Re: [PHP-WEBMASTER] Re: [PHP-DEV] Re: [PHP-WEBMASTER] Re: [PHP Wiki] new user: fabpot
Maybe the time has come for the adoption of some actual bylaws which succintly state who merits voting privileges and who may propose an RFC. If one reads 2.II.a of https://wiki.php.net/rfc/howto, that document indicates that the ability to propose an RFC does not automatically confer one with voting privileges, but the document is informational and and lacks the binding authority of an official bylaws. I respectfully suggest the adoption of bylaws so that it should be abundantly clear to every PHP user and contributor as to what rights each repectively has. SL - Original Message - From: Ferenc Kovacs tyr...@gmail.com To: Hannes Magnusson hannes.magnus...@gmail.com Cc: Pierre Joye pierre@gmail.com; PHP Development internals@lists.php.net; Johannes Schlüter johan...@schlueters.de; PHP Webmaster ML php-webmas...@lists.php.net; Peter Cowburn sala...@php.net; PHP Webmaster webmas...@php.net; Fabien Potencier fabien.potenc...@gmail.com; Derick Rethans der...@php.net Sent: Friday, March 01, 2013 4:26 PM Subject: Re: [PHP-WEBMASTER] Re: [PHP-DEV] Re: [PHP-WEBMASTER] Re: [PHP Wiki] new user: fabpot 2013.03.01. 22:52, Hannes Magnusson hannes.magnus...@gmail.com ezt írta: On Fri, Mar 1, 2013 at 1:19 PM, Johannes Schlüter johan...@schlueters.de wrote: Derick Rethans der...@php.net wrote: Exactly, this random apply rules nonsense needs to stop. I have nothing against Fabien voting but there is nowhere written who can vote or not (no, the voting RFC is too vague as well). I for one, would like to see a much stricter list of people who can vote. I often wonder about many names on the list of voters, there are names I have never seen ... which is really weird in my opinion. Either make it open for everybody and his dog or make a clear restriction. Currently the easiest way to get voting karma is to say you'll be creating an RFC, as anyone with karma in that namespace can automatically vote because votes happen in that namespace. Anyones mother can create a RFC (and therefore vote on anything), but if you just want to vote then you need to get approval from internals@. That voting RFC is btw really weird, I don't know how it got accepted. People with php.net SVN accounts that have contributed code to PHP is particularly funny as it disqualifies everyone working on docs, websites, infrastructure and whatnot (we don't however have separate roles for your karma level, so anyone with VCS account has full wiki privileges and can therefore vote). And considering the next part: Representatives from the PHP community, that will be chosen by those with php.net SVN accounts Is even more awesome, as the people working on docs, websites and infrastructure can choose those community representatives - without being able to vote themselves. All they have to do is I now pronounce you community representative. Hurray! I like the old approach better. When no clear consensus were reached, we would vote. Anyone in the world could vote on the mailinglist, and votes were creatively interpreted grouping people with karma vs community. Doing the same with polling is however difficult. Its a whole lot easier to spot fraud emails then it is to spot people signing up with multiple wiki accounts with the intentions of skewing the results. -Hannes only people with people with php.net accounts or with manually granted voting wiki group membership can vote. I have no idea who or on what ground can hand out voting ground membership, last time when somebody requested that (William, lead of propel) went unanswered. this is how currently the wiki voting works. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Optimizer+ bugreps
On 02/03/13 09:34, Pierre Joye wrote: Having it in peck right now allows that. But as of now it is not a PHP.net project so it makes little sense to have it listed there. On Mar 2, 2013 10:33 AM, Terry Ellison te...@ellisons.org.uk mailto:te...@ellisons.org.uk wrote: At what point is O+ reporting going to be possible through https://bugs.php.net/ ? I realize that this is a bit of a catch-22, but surely it would be better to allow properly tracked open bug reporting sooner rather later? Thanks Pierre, I understand and that's why I mentioned catch-22. AFAIK, there's no open bug and issue reporting available prior to its formal adoption, event though we all realize that it's going to be pretty much inevitable -- for compelling reasons -- and by the time it is adopted the first release will be a fait accompli.
Re: [PHP-DEV] Optimizer+ bugreps
On 3/2/13 3:19 AM, Terry Ellison wrote: On 02/03/13 09:34, Pierre Joye wrote: Having it in peck right now allows that. But as of now it is not a PHP.net project so it makes little sense to have it listed there. On Mar 2, 2013 10:33 AM, Terry Ellison te...@ellisons.org.uk mailto:te...@ellisons.org.uk wrote: At what point is O+ reporting going to be possible through https://bugs.php.net/ ? I realize that this is a bit of a catch-22, but surely it would be better to allow properly tracked open bug reporting sooner rather later? Thanks Pierre, I understand and that's why I mentioned catch-22. AFAIK, there's no open bug and issue reporting available prior to its formal adoption, event though we all realize that it's going to be pretty much inevitable -- for compelling reasons -- and by the time it is adopted the first release will be a fait accompli. Bugs can (and have been) reported via https://github.com/zend-dev/ZendOptimizerPlus/issues I'm sure email reports will also do fine in the interim. Chris -- christopher.jo...@oracle.com http://twitter.com/ghrd Newly updated, free PHP Oracle book: http://www.oracle.com/technetwork/topics/php/underground-php-oracle-manual-098250.html -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] VCS Account Request: dlsniper
I want to help out with bug handling (as Rasmus indicated on IRC) -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: VCS Account Request: dlsniper
VCS Account Approved: dlsniper approved by rasmus \o/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE] Integrating Zend Optimizer+ into the PHP distribution
On 2013-02-27, Zeev Suraski z...@zend.com wrote: On 27 2013, at 18:58, Anthony Ferrara ircmax...@gmail.com wrote: Zeev et al, I just want to put my justification for the only if no delay vote. I voted that way because we're already at a significant delay. If this vote was a month ago when O+ was suggested first, I would definitely have voted for delay. In fact IIRC I proposed a delay back then. But after a month, I think delaying much further would be imprudent. Fair enough! Here's mine for delaying: I believe our users will much appreciate a release with an opcode cache that's several months delayed vs. one that's without an opcode cache several months early. If the 5.4 adoption rate (or complete lack thereof) is any indication - very few are eagerly waiting for 5.5. In fact, in a year's time, when we all gear up to release 5.6 (based on current frequency) - 5.5 is almost guaranteed to have next to no traction in our userbase. A bundled opcode cache might be the killer feature that makes the difference. I agree with zeev here. The opcode cache is one of the most important thing for adoption. With apc not being 5.4 compatible and 5.3 eol with 5.6, there is no real transition for people relying on an opcode cache if we don't delay 5.5. That's the only reason why Julien and I so far delayed it. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: VCS Account Request: ardbiesheuvel
On Thu, Jan 17, 2013 at 8:18 AM, PHP Group gr...@php.net wrote: rasmus approved ardbiesheuvel account request \o/ Are you a different guy from abies (with an @ewi.tudelft.nl address)? Credited as the author of Firebird/InterBase driver for PDO Interbase... The abies account is still active.. -Hannes -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Optimizer+ bugreps
On 02/03/13 17:42, Christopher Jones wrote: I realize that this is a bit of a catch-22, but surely it would be better to allow properly tracked open bug reporting sooner rather later? Bugs can (and have been) reported via https://github.com/zend-dev/ZendOptimizerPlus/issues I'm sure email reports will also do fine in the interim. I guess this is a case of Du, my bad. Zeev gave the github URI in his initial announcement. I should have done a 1+1 ... Thanks Chris, sometimes an =2 is very useful :oops; //Terry
Re: [PHP-DEV] Re: VCS Account Request: ardbiesheuvel
On 3 March 2013 07:48, Hannes Magnusson hannes.magnus...@gmail.com wrote: On Thu, Jan 17, 2013 at 8:18 AM, PHP Group gr...@php.net wrote: rasmus approved ardbiesheuvel account request \o/ Are you a different guy from abies (with an @ewi.tudelft.nl address)? Credited as the author of Firebird/InterBase driver for PDO Interbase... The abies account is still active.. Yes, that is me. I didn't realize the old account was still active after all these years. -- Ard. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE] Integrating Zend Optimizer+ into the PHP distribution
On Thu, Feb 28, 2013 at 2:53 PM, Pierre Joye pierre@gmail.com wrote: On Wed, Feb 27, 2013 at 5:12 PM, Zeev Suraski z...@zend.com wrote: Based on the overwhelming response, the vote is now open J https://wiki.php.net/rfc/optimizerplus Voting ends March 7th. ok, given the total lack of answers, mistakes and misleading wording in the RFC and lack of releases in PECL (which is a pre requise since quite some time to get in core), I'd to vote -1 for now. +1, there should be a option release at PECL, which will give the O+ more feedback and test thanks It will surely won't change anything but I stand to what we discuss. -- Pierre @pierrejoye -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- Laruence Xinchen Hui http://www.laruence.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] SPKAC (FR #38917, pull 267)
Hi! I've reviewed the pull 267 and it seems to be finally ready, at least I can't see any problem with it. Is 5.5 still open for adding self-contained functions or should it remain in master? Thanks, -- 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] [VOTE] Integrating Zend Optimizer+ into the PHP distribution
hi Zeev, On Sun, Mar 3, 2013 at 8:02 AM, Zeev Suraski z...@zend.com wrote: ok, given the total lack of answers, mistakes and misleading wording in the RFC and lack of releases in PECL (which is a pre requise since quite some time to get in core), I'd to vote -1 for now. +1, there should be a option release at PECL, which will give the O+ more feedback and test There is one, its the third option. Ok this is getting ridiculous. How Don’t integrate Optimizer+ to PHP can be remotely related to the available of o+ via PECL? No matter the results, having o+ available in PECL for 5.5 is a very good thing and many are expecting as well. Not doing it means that only 5.5 is supported and that defeats the whole purpose of having one opcode cache to rule them all. Why? Because we will still have to use most of our resources to support APC and wincache for 5.3 and 5.4. At some point I think I will simply do it myself and be done with this sterile discussion, it is OSS anyway and the license allows anyone to do it. Cheers, -- Pierre @pierrejoye -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] [VOTE] Integrating Zend Optimizer+ into the PHP distribution
How Don't integrate Optimizer+ to PHP can be remotely related to the available of o+ via PECL? Actually it seems as if some of the original text got lost when I switched to the active vote, but it used to read 'Don't integrate Optimizer+ to PHP, release only in PECL'. My bad. Zeev -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE] Integrating Zend Optimizer+ into the PHP distribution
On Sun, Mar 3, 2013 at 8:21 AM, Zeev Suraski z...@zend.com wrote: How Don't integrate Optimizer+ to PHP can be remotely related to the available of o+ via PECL? Actually it seems as if some of the original text got lost when I switched to the active vote, but it used to read 'Don't integrate Optimizer+ to PHP, release only in PECL'. My bad. No offense and pls do not see what I will say here as an attempt to block it, as I really want o+ in core. I think this RFC should be fixed (fix wording to represent the actual actions, s,integration,bundlingcleanup,), votes options added to cover what has been discussed. Add a roadmap as well for the further steps that can/could/will be taken to make o+ even better while being in core. The options should include PECL, either it is in core or not. So you can get an idea about how many people wants 5.5 support and releases as well. Cheers, -- Pierre @pierrejoye -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE] Integrating Zend Optimizer+ into the PHP distribution
On 03/02/2013 11:25 PM, Pierre Joye wrote: On Sun, Mar 3, 2013 at 8:21 AM, Zeev Suraski z...@zend.com wrote: How Don't integrate Optimizer+ to PHP can be remotely related to the available of o+ via PECL? Actually it seems as if some of the original text got lost when I switched to the active vote, but it used to read 'Don't integrate Optimizer+ to PHP, release only in PECL'. My bad. No offense and pls do not see what I will say here as an attempt to block it, as I really want o+ in core. I think this RFC should be fixed (fix wording to represent the actual actions, s,integration,bundlingcleanup,), votes options added to cover what has been discussed. Add a roadmap as well for the further steps that can/could/will be taken to make o+ even better while being in core. The options should include PECL, either it is in core or not. So you can get an idea about how many people wants 5.5 support and releases as well. The RFC is about integrating O+ into PHP which can by definition only happen in 5.5 and later. The essential questions being asked by the RFC are whether to delay 5.5 for it, no delay and wait until the next version, or don't integrate at all the last of which implies external-only distribution either through pecl or individual distros simply packaging it from Github. And your beef about integration vs. bundling is rather nit-picky. The first step towards integration is getting it in. How much integration is done will depend on what people come up with. I have a pull request in for at least one level of integration that will allow it to save a stat call by integrating more closely with the sapi layer to save that initial stat if the sapi layer can pull it from the server layer. That is more than mere bundling, but it should also be rather safe to do. What we do about earlier versions is a completely separate and mostly unrelated issue. There is no real reason not to support those via pecl, but that isn't what this RFC is about. And, like you say, there is nothing stopping you or anybody else from making a pointer to it from pecl. -Rasmus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
