Re: [PHP-DEV] [RFC] Replace the flex-based scanner with an re2c [1] based lexer
On 04.03.2008 12:38, Marcus Boerger wrote: This sounds like we are going to do the same mistake over and over and over again. Who is forcing a hard time line on us? Why are we late in the develoment I don't get it at all. Right. Please take more time if needed, no need to rush and release something half-working. If it takes several months to prepare 5.3 release, let it be so. After all, we're not a commercial company that has to roll out a release every couple of months under pressure of share holders and overall competition. -- Wbr, Antony Dovgal -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Replace the flex-based scanner with an re2c [1] based lexer
Hello Andi, Tuesday, March 4, 2008, 7:51:07 AM, you wrote: Hi Marcus, Johannes, and all, First of all let me say that I have no conceptual problem with replacing the scanner with re2c. If it's cleaner, performs better and a better maintained piece of software (let's hope Marcus doesn't get run over) then we can move to re2c. There are a few important things to consider though: - There is a huge PHP/MySQL community in the far east especially in Japan. You may not hear as much from them because they mostly don't post on our public lists but it's large. They very much depend on multibyte support and it works well for them (I have talked to several people in those communities). Shift-JIS is a matter of fact for those communities. We can't just dump them in PHP 5.3. - We need to make sure that we have a streams story that works and existing functionality is supported by it (sounds like this is almost complete so probably not high risk). - We should make sure we can achieve compatibility including supporting functionality like declare(...) which is used by some including multibyte guys. I haven't heard of a reason why this couldn't be possible with RE2C. I think all the above is doable but we shouldn't ship without accomplishing that 100% compatibility especially telling the non-Latin world that we will stop supporting them. So at the end of the day it all boils down to timing. I have been expecting Johannes to cut a beta any day now (I realize Sun acquisition somewhat postponed his schedule). PHP 5.3 is on a pretty good track to a good stable release cycle. I think re-engineering a core piece of the engine at this point adds considerable risk and would definitely prolong the release cycle. So while I'm supportive of embracing RE2C if we get commitment to reach that 100% compatibility including multibyte support, I don't quite understand the sense of urgency and why we'd want to introduce this risk so late in the development of PHP 5.3. This is a risk the release manager shouldn't really be willing to take. Rewriting this multibyte support will require time and interaction with the communities that are currently using it to make sure that it meets their needs. It will not be a trivial project. We can definitely work towards RE2C in parallel and as Stas said the engine hasn't really been changing very much recently to make this hard (we finished our todos for 5.3). We could even branch off PHP 5.4 right after RC1 for PHP 5.3 and therefore reduce the time where this patch would need to be maintained separately (although I think it can already be maintained in a branch). Let's consider all the angles in addition to wanting to get the code in the tree asap. Andi This sounds like we are going to do the same mistake over and over and over again. Who is forcing a hard time line on us? Why are we late in the develoment I don't get it at all. We haven't done all steps that were on our radar for 5.3. Now that we finally found time to address this we should do it. Otherwise the consequence is just that we have to do a 5.4 version immediately. What is the reason for that, who is more happy with a 5.3 now? Are we a company that makes money with selling upgrades? Best regards, Marcus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Bug #44087
Jani is right, this is not a PHP bug. You need to configure your system correctly to make sure the libs are checked in the right order for They are - per the bug report, the ordering is correct: # ldconfig -p | grep -i xml2 libxml2.so.2 (libc6,x86-64) = /usr/local/lib/libxml2.so.2 libxml2.so.2 (libc6,x86-64) = /usr/lib64/libxml2.so.2 libxml2.so (libc6,x86-64) = /usr/local/lib/libxml2.so libxml2.so (libc6,x86-64) = /usr/lib64/libxml2.so shared libraries and also make sure that other components that rely on libxml2 aren't pulling it in from another place. PHP is not going to pull it in from 2 different places. Really more of a php-install list So this appears to be the crux of it. As rrichards points out in his latest bug comment, removing --with-xsl makes the linking work. However, I've already built my own libxslt for just these dependency reasons (against the newly built libxml2), and ordering/linking appears correct: # ldconfig -p | grep xslt libxslt.so.1 (libc6,x86-64) = /usr/local/lib/libxslt.so.1 libxslt.so.1 (libc6,x86-64) = /usr/lib64/libxslt.so.1 libxslt.so (libc6,x86-64) = /usr/local/lib/libxslt.so libxslt.so (libc6,x86-64) = /usr/lib64/libxslt.so libexslt.so.0 (libc6,x86-64) = /usr/local/lib/libexslt.so.0 libexslt.so.0 (libc6,x86-64) = /usr/lib64/libexslt.so.0 libexslt.so (libc6,x86-64) = /usr/local/lib/libexslt.so libexslt.so (libc6,x86-64) = /usr/lib64/libexslt.so # ldd /usr/local/lib/libxslt.so.1 libxml2.so.2 = /usr/local/lib/libxml2.so.2 (0x002a95699000) libz.so.1 = /usr/lib64/libz.so.1 (0x002a958d8000) libm.so.6 = /lib64/tls/libm.so.6 (0x002a959eb000) libc.so.6 = /lib64/tls/libc.so.6 (0x002a95b71000) libdl.so.2 = /lib64/libdl.so.2 (0x002a95da7000) /lib64/ld-linux-x86-64.so.2 (0x00552000) # ldd libexslt.so.0 libgcrypt.so.11 = /usr/lib64/libgcrypt.so.11 (0x002a95673000) libgpg-error.so.0 = /usr/lib64/libgpg-error.so.0 (0x002a957be000) libxslt.so.1 = /usr/local/lib/libxslt.so.1 (0x002a958c1000) libxml2.so.2 = /usr/local/lib/libxml2.so.2 (0x002a959f9000) libz.so.1 = /usr/lib64/libz.so.1 (0x002a95c38000) libm.so.6 = /lib64/tls/libm.so.6 (0x002a95d4b000) libc.so.6 = /lib64/tls/libc.so.6 (0x002a95ed1000) libnsl.so.1 = /lib64/libnsl.so.1 (0x002a96107000) libdl.so.2 = /lib64/libdl.so.2 (0x002a9621f000) /lib64/ld-linux-x86-64.so.2 (0x00552000) So again, all appears kosher to me. Supplying the --with-xsl=/usr/local should point PHP to my compiled version of the library, and --with-libxml-dir=/usr/local should do similar for its respective library. And each library is linking to the underlying same libxml2 version, so there aren't two different ones in use, that I can see. H -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] PHP6 floatval() BC issue
Hi all, playing around with PHP 6 I noticed the following BC issue: floatval(4.2foo) gives an E_NOTICE A non well formed numeric value encountered. The type casting (float)4.2foo still works as before. The change was introduced with the conversion of floatval() to zend_parse_parameters with revision 1.43 of ext/standard/type.c on 2006/09/24 18:23:47 by pollita (PHP6 Updates). In my opinion floatval() should be restored to the previous behavour because a) the documentation for floatval itself uses a non well formed value in the example and b) to keep it the same as type casting to (float). Or would the proper procedure for me be to open a ticket in the bug tracker? - Chris -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Copy a good idea: Ubuntu brainstorm
Hi all, As many probably have noticed, the internals mailinglist is flushed with ideas and people discussing about it. Although this is highly valuable, it makes looking through the e-mail list almost a daily task. Ubuntu QA has a nice solution for this: Ubuntu brainstorm (http://brainstorm.ubuntu.com). (They in terms got it from Dell.) On that site you can give ideas and others can comment and vote on it. This gives a nice overview what the community thinks is important and is more accessible and more clear than de discussions on the list. Also this would free up the mailing list for questions about writing PHP extensions and working on the internals. Setting this up might be quite some work, but perhaps our friends of Ubuntu QA are willing to share their webapp. Best regards, Arnold -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Replace the flex-based scanner with an re2c [1] based lexer
Hi! Right. Please take more time if needed, no need to rush and release something half-working. If it takes several months to prepare 5.3 release, let it be so. With this approach we would never release 5.3 - each couple of months somebody would have a cool idea which would only require initial commit and 2-3 months work on it on CVS, which delays the release - and then it goes to the next idea. We should cut it off somewhere - not because these ideas are bad - they aren't, but because we have to have releases. The best idea is worth nothing for the users unless it's part of the release. 5.3 is not the last version of PHP, and we have quite a bunch of stuff there already - so I think it makes sense to have release of what we have or will have soon, all while continuing to develop the ideas for next versions. After all, we're not a commercial company that has to roll out a release every couple of months under pressure of share holders and overall competition. If you think that because PHP project is not a commercial company it doesn't have to adhere to the laws of markets, popularity and users expectations - you are mistaken. We still have to take into account millions of PHP users, even though they don't pay us money directly. And it's open source which was release often last time I checked ;) -- Stanislav Malyshev, Zend Software Architect [EMAIL PROTECTED] http://www.zend.com/ (408)253-8829 MSN: [EMAIL PROTECTED] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Replace the flex-based scanner with an re2c [1] based lexer
Hello Andi, Tuesday, March 4, 2008, 7:51:07 AM, you wrote: Hi Marcus, Johannes, and all, First of all let me say that I have no conceptual problem with replacing the scanner with re2c. If it's cleaner, performs better and a better maintained piece of software (let's hope Marcus doesn't get run over) then we can move to re2c. There are a few important things to consider though: - There is a huge PHP/MySQL community in the far east especially in Japan. You may not hear as much from them because they mostly don't post on our public lists but it's large. They very much depend on multibyte support and it works well for them (I have talked to several people in those communities). Shift-JIS is a matter of fact for those communities. We can't just dump them in PHP 5.3. - We need to make sure that we have a streams story that works and existing functionality is supported by it (sounds like this is almost complete so probably not high risk). - We should make sure we can achieve compatibility including supporting functionality like declare(...) which is used by some including multibyte guys. I haven't heard of a reason why this couldn't be possible with RE2C. I think all the above is doable but we shouldn't ship without accomplishing that 100% compatibility especially telling the non-Latin world that we will stop supporting them. So at the end of the day it all boils down to timing. I have been expecting Johannes to cut a beta any day now (I realize Sun acquisition somewhat postponed his schedule). PHP 5.3 is on a pretty good track to a good stable release cycle. I think re-engineering a core piece of the engine at this point adds considerable risk and would definitely prolong the release cycle. So while I'm supportive of embracing RE2C if we get commitment to reach that 100% compatibility including multibyte support, I don't quite understand the sense of urgency and why we'd want to introduce this risk so late in the development of PHP 5.3. This is a risk the release manager shouldn't really be willing to take. Rewriting this multibyte support will require time and interaction with the communities that are currently using it to make sure that it meets their needs. It will not be a trivial project. We can definitely work towards RE2C in parallel and as Stas said the engine hasn't really been changing very much recently to make this hard (we finished our todos for 5.3). We could even branch off PHP 5.4 right after RC1 for PHP 5.3 and therefore reduce the time where this patch would need to be maintained separately (although I think it can already be maintained in a branch). Let's consider all the angles in addition to wanting to get the code in the tree asap. Andi Give me any reason why we need 5.4 at this point? Any single one? Are you having a bet or a deal about 5.3 release date? And what is the deal, you do whatever you think goes in and that's a law? Best regards, Marcus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Replace the flex-based scanner with an re2c [1] based lexer
Hi! Improving on that statement: The coolest feature ever is worth absolutely nothing unless it is documented. I agree with the intent - documentation is *very* important. Even though, people use undocumented features too (probably cursing the lazy developers on the way ;) BTW, as far as I remember, we have at least 4 undocumented features right now sitting in 5.3 CVS, so if anybody wants to do something cool, that's a good place: - Nowdocs aren't documented - .htaccess-like .ini files undocumented - [HOST=] and [PATH=] .ini sections undocumented - new version constants undocumented -- Stanislav Malyshev, Zend Software Architect [EMAIL PROTECTED] http://www.zend.com/ (408)253-8829 MSN: [EMAIL PROTECTED] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] [RFC] Replace the flex-based scanner with an re2c [1] based lexer
-Original Message- From: Hannes Magnusson [mailto:[EMAIL PROTECTED] Sent: Tuesday, March 04, 2008 11:18 AM To: Stas Malyshev Cc: Antony Dovgal; Marcus Boerger; Andi Gutmans; internals@lists.php.net Subject: Re: [PHP-DEV] [RFC] Replace the flex-based scanner with an re2c [1] based lexer Improving on that statement: The coolest feature ever is worth absolutely nothing unless it is documented. Don't care if its a new language construct, new class, function or method, optional parameter, new syntax in php.ini, errorlevel, dropped warnings or an awesome --enable-zend-multibyte configure switch. If it isn't documented its totally useless for anyone not reading php-cvs, zend-engine-cvs and this list daily. I'll hunt you all down and make you eat 1kg of vegetables each day after the 5.3 release untill proper documentation and upgrade guides have been written. Mark my words my friends, mark my words! ;) Why do you say it's not documented? http://www.aconus.com/~oyaji/www/apache_linux_php.htm http://tinyurl.com/2o8pq2 OK just kidding and I agree it would be nice to have it better documented in the mainstream docs. As it applies mostly to the Asian users though (Chinese/Japanese) who usually seek localized docs it's probably not as good as it should be in php.net. Andi -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Undocumented 5.3 features
On Tue, Mar 4, 2008 at 8:22 PM, Stanislav Malyshev [EMAIL PROTECTED] wrote: I agree with the intent - documentation is *very* important. Even though, people use undocumented features too (probably cursing the lazy developers on the way ;) Indeed. And in few years noone has a clue wtf all this code is about or how to use it even wondering if it would even work. Testing said features is equally as important to make sure the feature stay working and not removed since noone could figure out how to use it *cough*zend-multibyte*cough*. BTW, as far as I remember, we have at least 4 undocumented features right now sitting in 5.3 CVS, so if anybody wants to do something cool, that's a good place: - Nowdocs aren't documented http://docs.php.net/manual/en/language.types.string.php#language.types.string.syntax.nowdoc - .htaccess-like .ini files undocumented Heh? You mean the .htaccess FastCGI thingy? - [HOST=] and [PATH=] .ini sections undocumented Richard was looking into that one last time I knew. - new version constants undocumented Those were quick and easy job: http://docs.php.net/manual/en/reserved.constants.php - Functions/features throwing E_DEPRECATED - ?: - __callStatic I think is still undocumented - Few stream context options - All the new datetime and spl stuff - GC - New E_STRICT/E_FATAL/E_WARNINGs (like we did with the 5.2 release) And bunch of other small things here and there. -Hannes -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: Docs for 5.3!
Hi! - Nowdocs aren't documented - .htaccess-like .ini files undocumented - [HOST=] and [PATH=] .ini sections undocumented - new version constants undocumented BTW, not sure if other things from the top of NEWS file are documented either... -- Stanislav Malyshev, Zend Software Architect [EMAIL PROTECTED] http://www.zend.com/ (408)253-8829 MSN: [EMAIL PROTECTED] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Replace the flex-based scanner with an re2c [1] based lexer
On Tue, Mar 4, 2008 at 8:38 PM, Andi Gutmans [EMAIL PROTECTED] wrote: OK just kidding and I agree it would be nice to have it better documented in the mainstream docs. As it applies mostly to the Asian users though (Chinese/Japanese) who usually seek localized docs it's probably not as good as it should be in php.net. The Japanese docs are 100% up-to-date with the English docs so they shouldn't have any problem reading out docs. In fact, if you do changes in the en/ tree Takagi Masahiro will have it translated within 24hours - even if that change spanned 50files. Not kidding. -Hannes -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Replace the flex-based scanner with an re2c [1] based lexer
On Tue, Mar 4, 2008 at 8:38 PM, Andi Gutmans [EMAIL PROTECTED] wrote: Why do you say it's not documented? http://www.aconus.com/~oyaji/www/apache_linux_php.htm http://tinyurl.com/2o8pq2 According to the latter link, our windows binaries don't enable zend-multibyte, is this true? -Hannes -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: Undocumented 5.3 features
Hi! - Nowdocs aren't documented http://docs.php.net/manual/en/language.types.string.php#language.types.string.syntax.nowdoc Ah, great! - .htaccess-like .ini files undocumented Heh? You mean the .htaccess FastCGI thingy? yep, that thingy. - new version constants undocumented Those were quick and easy job: http://docs.php.net/manual/en/reserved.constants.php Ok, great, you are ahead of me :) -- Stanislav Malyshev, Zend Software Architect [EMAIL PROTECTED] http://www.zend.com/ (408)253-8829 MSN: [EMAIL PROTECTED] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] RFC: How PHP utilizes the Google SoC
The Google Summer of Code sponsors students to work on Open Source projects over each summer. This RFC introduces guidelines and goals involving how we handle the SoC process. Synopsis: - Nominate an administrator early, encourage idea development year round, and focus on nominating current contributors over new ones. The Administrator: - The SoC Administrator is designated - hopefully before February 1. Administrative duties: - - organize the ideas page with summer long tasks - evaluate PHP project contributors for possible mentors and students - mind all official SoC guidelines/timelines - begin process for the following year Choosing projects: - An official goal[1] of SoC is to encourage new contributors to the Open Source world. This RFC selfishly proposes an alternative yet defined angle for accomplishing this goal. We first encourage students to become accustomed to the PHP process, peers, and learn the quirks that go on around here. And later, they may apply for an SoC project. Benefits: - efficiency - can start work today - in-house feel - better retention - a higher bus factor Downsides: - distracted by other php.net tasks - encourages less outside proposals - delays - i'll wait for the summer The benefits are good, and while kept in mind the downsides can be dealt with. Dealing with the downsides: - - students are discouraged by peers to work on other parts of the PHP project - peers are encouraged to take on the students current php.net tasks - be clear that all ideas by anyone are accepted, but in-house is preferred - maintain a How can I help PHP today? guide with HOWTO: - create and submit a patch - resolve bugs - help maintain a pecl extension - write unit tests - write documentation, and/or translate - deal with user notes - ... Ideas: - Idea generation and brain storming is encouraged all year, and ideas may be implemented at any time by any person. But once the summer nears, they (the ones not yet started) essentially become reserved as possible SoC proposals. Ideas that directly help php.net operations receive moderate preference. Eventually idea management becomes its own beast, with SoC ideas being only a small part of that task. This year: - This year we assign both new and current people, but in future years encourage people to join the PHP project first, and then potentially utilize the Google SoC later. Regards, Philip [1] http://code.google.com/soc/2008/faqs.html#0.1_goals -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: RFC: How PHP utilizes the Google SoC
Philip Olson wrote: The SoC Administrator is designated - hopefully before February 1. Somewhat behind the ball, are we? :o) -- Edward Z. YangGnuPG: 0x869C48DA HTML Purifier http://htmlpurifier.org Anti-XSS Filter [[ 3FA8 E9A9 7385 B691 A6FC B3CB A933 BE7D 869C 48DA ]] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: RFC: How PHP utilizes the Google SoC
Philip Olson wrote: The SoC Administrator is designated - hopefully before February 1. Marcus was last year, he is again this year. Somewhat behind the ball, are we? :o) Nothing is behind the walls... for once :) -- David, Re-read what you are replying. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: RFC: How PHP utilizes the Google SoC
David Coallier wrote: Marcus was last year, he is again this year. Gotcha. Thanks for the clarification. -- Edward Z. YangGnuPG: 0x869C48DA HTML Purifier http://htmlpurifier.org Anti-XSS Filter [[ 3FA8 E9A9 7385 B691 A6FC B3CB A933 BE7D 869C 48DA ]] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: How PHP utilizes the Google SoC
On Tue, Mar 4, 2008 at 5:17 PM, Philip Olson [EMAIL PROTECTED] wrote:
The Google Summer of Code sponsors students to work on Open Source
projects over each summer. This RFC introduces guidelines and goals
involving how we handle the SoC process.
[snip=important info]
Philip (or anyone else who can answer);
According to the information I've read (and I'll admit, I've
*heard* of the GSoC, but am by no means familiar with it), the
organization receives a small stipend as the representative group. My
question is: how is this usually spent?
The reason I ask is because I'd be very interested in mentoring a
student on a project if we can use this money to help move the RFC
Wiki (or similar) idea forward. Besides, I'd be killing two birds
with one stone as it was, I was trying to figure out how I'd
afford the box and bandwidth as it is, because the Wiki idea - as I
think others may agree - is an excellent step toward the future of the
development of PHP. So it's not an unselfish move on my part.
--
/Dan
Daniel P. Brown
Senior Unix Geek
? while(1) { $me = $mind--; sleep(86400); } ?
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: How PHP utilizes the Google SoC
On Mar 4, 2008, at 7:07 PM, Daniel Brown wrote: On Tue, Mar 4, 2008 at 5:17 PM, Philip Olson [EMAIL PROTECTED] wrote: The Google Summer of Code sponsors students to work on Open Source projects over each summer. This RFC introduces guidelines and goals involving how we handle the SoC process. [snip=important info] Philip (or anyone else who can answer); According to the information I've read (and I'll admit, I've *heard* of the GSoC, but am by no means familiar with it), the organization receives a small stipend as the representative group. My question is: how is this usually spent? The reason I ask is because I'd be very interested in mentoring a student on a project if we can use this money to help move the RFC Wiki (or similar) idea forward. Besides, I'd be killing two birds with one stone as it was, I was trying to figure out how I'd afford the box and bandwidth as it is, because the Wiki idea - as I think others may agree - is an excellent step toward the future of the development of PHP. So it's not an unselfish move on my part. Hello Daniel, Lack of funding is rarely a cause for such issues. Where there is a will, there is a free way. Many entities exist out there that are willing to donate boxes and bandwidth but people just need to find them. The wiki is moving forward after delays for many reasons including unknowns about if PHP wants a wiki (some people hate them), our chaotic nature, and lack of time. Lukas is now working on the wiki and it already has a domain (wiki.php.net) and CVS module (php-wiki- web) and once it goes online I have a feeling other new tools will start evolving. Just a guess. These were created yesterday. As for where the mentor SoC money goes, I think it finds its way towards random PHP user groups. Regards, Philip -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: How PHP utilizes the Google SoC
Philip Olson wrote: On Mar 4, 2008, at 7:07 PM, Daniel Brown wrote: On Tue, Mar 4, 2008 at 5:17 PM, Philip Olson [EMAIL PROTECTED] wrote: The Google Summer of Code sponsors students to work on Open Source projects over each summer. This RFC introduces guidelines and goals involving how we handle the SoC process. [snip=important info] Philip (or anyone else who can answer); According to the information I've read (and I'll admit, I've *heard* of the GSoC, but am by no means familiar with it), the organization receives a small stipend as the representative group. My question is: how is this usually spent? The reason I ask is because I'd be very interested in mentoring a student on a project if we can use this money to help move the RFC Wiki (or similar) idea forward. Besides, I'd be killing two birds with one stone as it was, I was trying to figure out how I'd afford the box and bandwidth as it is, because the Wiki idea - as I think others may agree - is an excellent step toward the future of the development of PHP. So it's not an unselfish move on my part. Hello Daniel, Lack of funding is rarely a cause for such issues. Where there is a will, there is a free way. Many entities exist out there that are willing to donate boxes and bandwidth but people just need to find them. The wiki is moving forward after delays for many reasons including unknowns about if PHP wants a wiki (some people hate them), our chaotic nature, and lack of time. Lukas is now working on the wiki and it already has a domain (wiki.php.net) and CVS module (php-wiki-web) and once it goes online I have a feeling other new tools will start evolving. Just a guess. These were created yesterday. As for where the mentor SoC money goes, I think it finds its way towards random PHP user groups. The money goes directly to the students. PHP as a project does not take any money. Technically we could, but we haven chosen in the past not to. -Rasmus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
