Re: [PHP-DEV] trunk is alive and open
On 31.03.2010, at 07:22, Rasmus Lerdorf wrote: On 03/30/2010 08:41 PM, Philip Olson wrote: It's awesome that PHP has so many great options for the next Release Manager because all of the proposed people would do great. However, I'd like to see Rasmus become RM. Not sure about the co-RM topic but Chris Jones comes to mind. I love the way these two guys handle things, and it feels like a nice balance. And while Rasmus may [or may not] deny his BDFL status, I'd love to see it in high gear especially now that he's funemployed. I didn't actually volunteer. I think someone misunderstood that at some point. I'll do it if nobody else will, but both Derick and David seem keen, and I think they should work it out between them. The whole concept of a non-technical co-rm person, is kind of a moot point I think. We all know that person is Lukas and he will do his thing regardless. That's not a knock, by the way, we need a process guy to offset my anti-process approach so that we can meet somewhere in the middle. Just FYI: I will no longer serve as the process guy, nor anything else really. Feel free to remove my karma. I may write the occasional post here still of course as I will continue to be a PHP end user. Context: I just feel that with the things I feel are right, I will just end up being tied up in a perpetual battle. Over the years I got a few things to go the way I wanted (wiki, a todo list, RFCs) but there are simply some fundamental things where I am no longer motivated to work with the status quo, but where I do not see a realistic chance if this ever changing. regards, Lukas Kahwe Smith m...@pooteeweet.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] trunk is alive and open
As I've mentioned in the past I think we are better off with shorter release cycles and less features per cycle. Reduces risk and enables us to push out value faster. For example, we have made (and are still making) significant performance enhancements to the runtime. It'd be a shame if that waited until Q4 for alpha. I think with traits, performance enhancements and a few additional changes we already have a pretty substantial version. +1 for quicker PHP releases. Seems like every 5.x release has changed the world. Would love to see smaller changes as it comes out. Less panic when planning upgrades. Brian. brianlm...@php.net -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] trunk is alive and open
Am 29.04.2010 07:28, schrieb Andi Gutmans: I think with traits, performance enhancements and a few additional changes we already have a pretty substantial version. +1 -- 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
Re: [PHP-DEV] trunk is alive and open
2010/4/29 Andi Gutmans a...@zend.com: -Original Message- From: Johannes Schlüter [mailto:johan...@schlueters.de] Sent: Tuesday, April 27, 2010 9:40 AM To: Pierre Joye Cc: Gwynne Raskind; Ilia Alshanetsky; Kalle Sommer Nielsen; Lukas Kahwe Smith; Andi Gutmans; Derick Rethans; PHP Developers Mailing List Subject: Re: [PHP-DEV] trunk is alive and open On Tue, 2010-04-27 at 17:46 +0200, Pierre Joye wrote: Before even thinking about a planning, we have to define what we want in and how we go further. ACK, I think it makes sense to define some key features we want for the next release (traits seem to be one). An issue with 5.3 was that whenever really defined that but only said let's backport from 6 and add all stuff coming in. I think it makes sense to define a set of key features (traits, what else?) and once these are implemented in an accepted way (not meaning stable but having an accepted design) make a release branch (either by branching of or locking trunk for bigger features or whatever) where stability of this is improved else we end up adding feature after feature and introducing problem after problem. As I've mentioned in the past I think we are better off with shorter release cycles and less features per cycle. Reduces risk and enables us to push out value faster. For example, we have made (and are still making) significant performance enhancements to the runtime. It'd be a shame if that waited until Q4 for alpha. I think with traits, performance enhancements and a few additional changes we already have a pretty substantial version. +1 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] trunk is alive and open
On 29.04.2010, at 08:38, Jérôme Loyet wrote: 2010/4/29 Andi Gutmans a...@zend.com: -Original Message- From: Johannes Schlüter [mailto:johan...@schlueters.de] Sent: Tuesday, April 27, 2010 9:40 AM To: Pierre Joye Cc: Gwynne Raskind; Ilia Alshanetsky; Kalle Sommer Nielsen; Lukas Kahwe Smith; Andi Gutmans; Derick Rethans; PHP Developers Mailing List Subject: Re: [PHP-DEV] trunk is alive and open On Tue, 2010-04-27 at 17:46 +0200, Pierre Joye wrote: Before even thinking about a planning, we have to define what we want in and how we go further. ACK, I think it makes sense to define some key features we want for the next release (traits seem to be one). An issue with 5.3 was that whenever really defined that but only said let's backport from 6 and add all stuff coming in. I think it makes sense to define a set of key features (traits, what else?) and once these are implemented in an accepted way (not meaning stable but having an accepted design) make a release branch (either by branching of or locking trunk for bigger features or whatever) where stability of this is improved else we end up adding feature after feature and introducing problem after problem. As I've mentioned in the past I think we are better off with shorter release cycles and less features per cycle. Reduces risk and enables us to push out value faster. For example, we have made (and are still making) significant performance enhancements to the runtime. It'd be a shame if that waited until Q4 for alpha. I think with traits, performance enhancements and a few additional changes we already have a pretty substantial version. +1 +1 regards, Lukas Kahwe Smith m...@pooteeweet.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] trunk is alive and open
On Apr 29, 2010, at 10:05 AM, Lukas Kahwe Smith wrote: -Original Message- From: Johannes Schlüter [mailto:johan...@schlueters.de] Sent: Tuesday, April 27, 2010 9:40 AM To: Pierre Joye Cc: Gwynne Raskind; Ilia Alshanetsky; Kalle Sommer Nielsen; Lukas Kahwe Smith; Andi Gutmans; Derick Rethans; PHP Developers Mailing List Subject: Re: [PHP-DEV] trunk is alive and open On Tue, 2010-04-27 at 17:46 +0200, Pierre Joye wrote: Before even thinking about a planning, we have to define what we want in and how we go further. ACK, I think it makes sense to define some key features we want for the next release (traits seem to be one). An issue with 5.3 was that whenever really defined that but only said let's backport from 6 and add all stuff coming in. I think it makes sense to define a set of key features (traits, what else?) and once these are implemented in an accepted way (not meaning stable but having an accepted design) make a release branch (either by branching of or locking trunk for bigger features or whatever) where stability of this is improved else we end up adding feature after feature and introducing problem after problem. As I've mentioned in the past I think we are better off with shorter release cycles and less features per cycle. Reduces risk and enables us to push out value faster. For example, we have made (and are still making) significant performance enhancements to the runtime. It'd be a shame if that waited until Q4 for alpha. I think with traits, performance enhancements and a few additional changes we already have a pretty substantial version. +1 +1 +1 -- Gwynne -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] trunk is alive and open
2010/4/30 Gwynne Raskind gwy...@darkrainfall.org: On Apr 29, 2010, at 10:05 AM, Lukas Kahwe Smith wrote: As I've mentioned in the past I think we are better off with shorter release cycles and less features per cycle. Reduces risk and enables us to push out value faster. For example, we have made (and are still making) significant performance enhancements to the runtime. It'd be a shame if that waited until Q4 for alpha. I think with traits, performance enhancements and a few additional changes we already have a pretty substantial version. +1 +1 +1 +1, where 1 is actually quite a large number. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] trunk is alive and open
-Original Message- From: Johannes Schlüter [mailto:johan...@schlueters.de] Sent: Tuesday, April 27, 2010 9:40 AM To: Pierre Joye Cc: Gwynne Raskind; Ilia Alshanetsky; Kalle Sommer Nielsen; Lukas Kahwe Smith; Andi Gutmans; Derick Rethans; PHP Developers Mailing List Subject: Re: [PHP-DEV] trunk is alive and open On Tue, 2010-04-27 at 17:46 +0200, Pierre Joye wrote: Before even thinking about a planning, we have to define what we want in and how we go further. ACK, I think it makes sense to define some key features we want for the next release (traits seem to be one). An issue with 5.3 was that whenever really defined that but only said let's backport from 6 and add all stuff coming in. I think it makes sense to define a set of key features (traits, what else?) and once these are implemented in an accepted way (not meaning stable but having an accepted design) make a release branch (either by branching of or locking trunk for bigger features or whatever) where stability of this is improved else we end up adding feature after feature and introducing problem after problem. As I've mentioned in the past I think we are better off with shorter release cycles and less features per cycle. Reduces risk and enables us to push out value faster. For example, we have made (and are still making) significant performance enhancements to the runtime. It'd be a shame if that waited until Q4 for alpha. I think with traits, performance enhancements and a few additional changes we already have a pretty substantial version. Andi
Re: [PHP-DEV] trunk is alive and open
+1 for a co-RM of Derick and Kalle On Tue, Apr 27, 2010 at 12:33 AM, Kalle Sommer Nielsen ka...@php.netwrote: Hi 2010/3/24 Lukas Kahwe Smith m...@pooteeweet.org: Yeah, lets get that clarified. Derick has stepped up and seems quite committed and nobody seemed to oppose him RMing the next release. In case he feels he needs support he can propose a co-RM, after all its important that the two RM's know and trust each other well so that they can speak with a consistent voice. I'll like to propose myself for RM'ing, or co-RM-ing with Derick, now David have said no in the last mail in this thread. I've been around the PHP development for a few years now. I don't have the large technical experince like Derick but I would still stand up for the challenge and responsibility of getting the next major version of PHP out and rolling. I once tried to come up with some suggestions about getting PHP6's old implementation on the track again but it didn't get much response. And I think we should decide on a version number and see if we can get an Alpha release out by Q4 this year if possible, since the current releases of new development branches have been taking forever during the last couple of years. -- regards, Kalle Sommer Nielsen ka...@php.net -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] trunk is alive and open
+1 for Derick and Kalle, and +1 for alpha by Q4. On Apr 27, 2010, at 8:53 AM, Ilia Alshanetsky wrote: +1 for a co-RM of Derick and Kalle On Tue, Apr 27, 2010 at 12:33 AM, Kalle Sommer Nielsen ka...@php.netwrote: Hi 2010/3/24 Lukas Kahwe Smith m...@pooteeweet.org: Yeah, lets get that clarified. Derick has stepped up and seems quite committed and nobody seemed to oppose him RMing the next release. In case he feels he needs support he can propose a co-RM, after all its important that the two RM's know and trust each other well so that they can speak with a consistent voice. I'll like to propose myself for RM'ing, or co-RM-ing with Derick, now David have said no in the last mail in this thread. I've been around the PHP development for a few years now. I don't have the large technical experince like Derick but I would still stand up for the challenge and responsibility of getting the next major version of PHP out and rolling. I once tried to come up with some suggestions about getting PHP6's old implementation on the track again but it didn't get much response. And I think we should decide on a version number and see if we can get an Alpha release out by Q4 this year if possible, since the current releases of new development branches have been taking forever during the last couple of years. -- regards, Kalle Sommer Nielsen ka...@php.net -- Gwynne -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] trunk is alive and open
Before even thinking about a planning, we have to define what we want in and how we go further. That being said, my vote remains the same as before. Cheers, On Tue, Apr 27, 2010 at 5:23 PM, Gwynne Raskind gwy...@darkrainfall.org wrote: +1 for Derick and Kalle, and +1 for alpha by Q4. On Apr 27, 2010, at 8:53 AM, Ilia Alshanetsky wrote: +1 for a co-RM of Derick and Kalle On Tue, Apr 27, 2010 at 12:33 AM, Kalle Sommer Nielsen ka...@php.netwrote: Hi 2010/3/24 Lukas Kahwe Smith m...@pooteeweet.org: Yeah, lets get that clarified. Derick has stepped up and seems quite committed and nobody seemed to oppose him RMing the next release. In case he feels he needs support he can propose a co-RM, after all its important that the two RM's know and trust each other well so that they can speak with a consistent voice. I'll like to propose myself for RM'ing, or co-RM-ing with Derick, now David have said no in the last mail in this thread. I've been around the PHP development for a few years now. I don't have the large technical experince like Derick but I would still stand up for the challenge and responsibility of getting the next major version of PHP out and rolling. I once tried to come up with some suggestions about getting PHP6's old implementation on the track again but it didn't get much response. And I think we should decide on a version number and see if we can get an Alpha release out by Q4 this year if possible, since the current releases of new development branches have been taking forever during the last couple of years. -- regards, Kalle Sommer Nielsen ka...@php.net -- Gwynne -- 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] trunk is alive and open
On Tue, 2010-04-27 at 17:46 +0200, Pierre Joye wrote: Before even thinking about a planning, we have to define what we want in and how we go further. ACK, I think it makes sense to define some key features we want for the next release (traits seem to be one). An issue with 5.3 was that whenever really defined that but only said let's backport from 6 and add all stuff coming in. I think it makes sense to define a set of key features (traits, what else?) and once these are implemented in an accepted way (not meaning stable but having an accepted design) make a release branch (either by branching of or locking trunk for bigger features or whatever) where stability of this is improved else we end up adding feature after feature and introducing problem after problem. johannes -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] trunk is alive and open
+1 For derick and Kalle 2010/4/27 Kalle Sommer Nielsen ka...@php.net: Hi 2010/3/24 Lukas Kahwe Smith m...@pooteeweet.org: Yeah, lets get that clarified. Derick has stepped up and seems quite committed and nobody seemed to oppose him RMing the next release. In case he feels he needs support he can propose a co-RM, after all its important that the two RM's know and trust each other well so that they can speak with a consistent voice. I'll like to propose myself for RM'ing, or co-RM-ing with Derick, now David have said no in the last mail in this thread. I've been around the PHP development for a few years now. I don't have the large technical experince like Derick but I would still stand up for the challenge and responsibility of getting the next major version of PHP out and rolling. I once tried to come up with some suggestions about getting PHP6's old implementation on the track again but it didn't get much response. And I think we should decide on a version number and see if we can get an Alpha release out by Q4 this year if possible, since the current releases of new development branches have been taking forever during the last couple of years. -- regards, Kalle Sommer Nielsen ka...@php.net -- 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] trunk is alive and open
Hi 2010/3/24 Lukas Kahwe Smith m...@pooteeweet.org: Yeah, lets get that clarified. Derick has stepped up and seems quite committed and nobody seemed to oppose him RMing the next release. In case he feels he needs support he can propose a co-RM, after all its important that the two RM's know and trust each other well so that they can speak with a consistent voice. I'll like to propose myself for RM'ing, or co-RM-ing with Derick, now David have said no in the last mail in this thread. I've been around the PHP development for a few years now. I don't have the large technical experince like Derick but I would still stand up for the challenge and responsibility of getting the next major version of PHP out and rolling. I once tried to come up with some suggestions about getting PHP6's old implementation on the track again but it didn't get much response. And I think we should decide on a version number and see if we can get an Alpha release out by Q4 this year if possible, since the current releases of new development branches have been taking forever during the last couple of years. -- regards, Kalle Sommer Nielsen ka...@php.net -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] trunk is alive and open
On 2010-03-24, David Soria Parra d...@php.net wrote: On 2010-03-24, Derick Rethans der...@php.net wrote: On Wed, 24 Mar 2010, Lukas Kahwe Smith wrote: Although I can see me doing RM as well (as proposed), I don't think having two tech people as RMs would be good and might result in unecessary discussions during a release phase (for sure there is a benifit splitting work while on rm is not available). I think it is good to have a co-RM that focus on community work. just as an information: I decided not to do RM for personal reasons. I think this will also make things simpler. - david -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] trunk is alive and open
It's awesome that PHP has so many great options for the next Release Manager because all of the proposed people would do great. However, I'd like to see Rasmus become RM. Not sure about the co-RM topic but Chris Jones comes to mind. I love the way these two guys handle things, and it feels like a nice balance. And while Rasmus may [or may not] deny his BDFL status, I'd love to see it in high gear especially now that he's funemployed. Regards, Philip -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] trunk is alive and open
On Mar 30, 2010, at 11:41 PM, Philip Olson wrote: It's awesome that PHP has so many great options for the next Release Manager because all of the proposed people would do great. However, I'd like to see Rasmus become RM. Not sure about the co-RM topic but Chris Jones comes to mind. I love the way these two guys handle things, and it feels like a nice balance. And while Rasmus may [or may not] deny his BDFL status, I'd love to see it in high gear especially now that he's funemployed. +1 -- Gwynne smime.p7s Description: S/MIME cryptographic signature
Re: [PHP-DEV] trunk is alive and open
2010/3/31 Philip Olson phi...@roshambo.org: And while Rasmus may [or may not] deny his BDFL status, I'd love to see it in high gear especially now that he's funemployed. +1 -- regards, Kalle Sommer Nielsen ka...@php.net -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] trunk is alive and open
On 03/30/2010 08:41 PM, Philip Olson wrote: It's awesome that PHP has so many great options for the next Release Manager because all of the proposed people would do great. However, I'd like to see Rasmus become RM. Not sure about the co-RM topic but Chris Jones comes to mind. I love the way these two guys handle things, and it feels like a nice balance. And while Rasmus may [or may not] deny his BDFL status, I'd love to see it in high gear especially now that he's funemployed. I didn't actually volunteer. I think someone misunderstood that at some point. I'll do it if nobody else will, but both Derick and David seem keen, and I think they should work it out between them. The whole concept of a non-technical co-rm person, is kind of a moot point I think. We all know that person is Lukas and he will do his thing regardless. That's not a knock, by the way, we need a process guy to offset my anti-process approach so that we can meet somewhere in the middle. -Rasmus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] trunk is alive and open
hi florian,
On Sat, Mar 27, 2010 at 03:28:39PM +0100, Florian Anderiasch wrote:
The core differences I'm seeing here is:
- DPL (Debian Project Leader) != PHP RM (Release Manager)
It's actually not even remotely comparable.
what would be more comparable would be the debian RM('s). and it's worth
pointing out that we don't elect those--instead we have a self-selecting
team who handle it. after a new version has been released, usually one
or two of them will become an SRM (Stable Release Manager), focusing on
the long-term-support issues for the new release, whereas the rest of
the team continues to focus on forming the next release.
sean
--
signature.asc
Description: Digital signature
Re: [PHP-DEV] trunk is alive and open
On 25.03.2010, at 22:58, Christopher Jones wrote: After considering what is needed by PHP, I believe the vote should primarily be thought of as a choice between Derick and David. If either wants to bring in a co-RM to share the load, then I suggest Lukas be first choice. I'd be happy with either Derick or David as RM. When voting, I'd give my +1 to David this time. We might enter a quick release cycle so the RM would change over quickly. Disclaimer: David works at Sun which was recently bought by Oracle. Personally I think its a good idea to switch RM after every release. Plus I am pretty certain that there are other people (like you Chris) in the php.net community that could take on the role I had for 5.3 (aka less technical more organizational). Aside from this while there is no need to ever rush anything, I would think that it would help a lot to get the RM's sorted out quickly, so I would really ask all people to quickly chime in with their preference, nominations or whatever else might matter to get this decision finalized. regards, Lukas Kahwe Smith m...@pooteeweet.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] trunk is alive and open
On Sat, Mar 27, 2010 at 11:12 AM, Lukas Kahwe Smith m...@pooteeweet.orgwrote: On 25.03.2010, at 22:58, Christopher Jones wrote: After considering what is needed by PHP, I believe the vote should primarily be thought of as a choice between Derick and David. If either wants to bring in a co-RM to share the load, then I suggest Lukas be first choice. I'd be happy with either Derick or David as RM. When voting, I'd give my +1 to David this time. We might enter a quick release cycle so the RM would change over quickly. Disclaimer: David works at Sun which was recently bought by Oracle. Personally I think its a good idea to switch RM after every release. Plus I am pretty certain that there are other people (like you Chris) in the php.net community that could take on the role I had for 5.3 (aka less technical more organizational). Aside from this while there is no need to ever rush anything, I would think that it would help a lot to get the RM's sorted out quickly, so I would really ask all people to quickly chime in with their preference, nominations or whatever else might matter to get this decision finalized. regards, Lukas Kahwe Smith m...@pooteeweet.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php I like the way how the debian guys elect the project leader: http://en.wikipedia.org/wiki/Debian#Project_organization http://en.wikipedia.org/wiki/File:Debian-organigram.png http://en.wikipedia.org/wiki/Schulze_method Tyrael
Re: [PHP-DEV] trunk is alive and open
On 27.03.2010 13:13, Ferenc Kovacs wrote: I like the way how the debian guys elect the project leader: http://en.wikipedia.org/wiki/Debian#Project_organization http://en.wikipedia.org/wiki/File:Debian-organigram.png http://en.wikipedia.org/wiki/Schulze_method Hi, while I do agree that they have a decent model there, I think this would be very hard to implement in PHP, even when ignoring the technical hurdles. The core differences I'm seeing here is: - DPL (Debian Project Leader) != PHP RM (Release Manager) It's actually not even remotely comparable. - It's for one year and also a somewhat representative role. I've not seen many RMs stand out to the public as representatives, but that's absolutely ok. It's mostly a technical position. - Debian has a decently high entry hurdle, before you're going to be a DD (Debian Developer) there's a lot of work and especially a lot of time involved. In PHP we've much more often have people pop out of nowhere, do a ton of work and vanish again. - Much in the Debian process is based on your trusted @debian.org GPG key - that's also used for any election talk and voting - afaik. OK, we got SVN accounts, that'd probably be a reasonable voting platform. - Although there are a lot more people involved in Debian than in PHP (at least that's my impression) I think the people inside the PHP project reading and deciding here is much smaller. To me this doesn't look as a everyone with a @php.net email address==svn account can vote would be anywhere close to the decisions ever made. TLDNR: I don't see many paralles to even start a decent comparison, PHP simply does not have this level of democracy where someone contributing some translated pages has the same vote as someone having been RM and doing core work for years. Greetings, Florian -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] trunk is alive and open
Lukas Kahwe Smith wrote: On 24.03.2010, at 11:08, Pierre Joye wrote: skills. You suggested Chris and I think he could do a great job. My Just to clarify as I mentioned this on IRC and not on here. I think it would be great to have Chris Jones do the organizational co-RM. For one I have great trust in him keeping a good overview of the priorities, plus he can also give some technical input, where I for example couldn't. Furthermore I was co-RM in the last release, we all know power corrupts so its good to rotate :) For those who might be concerned that he is to embedded at Oracle, I actually think its quite the opposite. I think it would be great for PHP to have him take an official role. I have full trust in his integrity and so it might be also a good signal after the entire PDO2 CLA debacle that we do have trust in working with people from big corps. regards, Lukas Kahwe Smith m...@pooteeweet.org Thanks for the comments. After considering what is needed by PHP, I believe the vote should primarily be thought of as a choice between Derick and David. If either wants to bring in a co-RM to share the load, then I suggest Lukas be first choice. I'd be happy with either Derick or David as RM. When voting, I'd give my +1 to David this time. We might enter a quick release cycle so the RM would change over quickly. Disclaimer: David works at Sun which was recently bought by Oracle. Chris -- Email: christopher.jo...@oracle.com Tel: +1 650 506 8630 Blog: http://blogs.oracle.com/opal/ Free PHP Book: http://tinyurl.com/ugpomhome -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] trunk is alive and open
On 2010-03-25, Christopher Jones christopher.jo...@oracle.com wrote: Disclaimer: David works at Sun which was recently bought by Oracle. Just to make sure everyone has the same information here: I leave Sun at the end of the month. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] trunk is alive and open
On 23.03.2010, at 23:04, Andi Gutmans wrote: What about defining a release manager for the next release? I think that is an important aspect of moving things forward. I also thought the dual RM in PHP 5.3 worked quite well although it is not necessarily a must. Yeah, lets get that clarified. Derick has stepped up and seems quite committed and nobody seemed to oppose him RMing the next release. In case he feels he needs support he can propose a co-RM, after all its important that the two RM's know and trust each other well so that they can speak with a consistent voice. regards, Lukas Kahwe Smith m...@pooteeweet.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] trunk is alive and open
hi, On Wed, Mar 24, 2010 at 11:02 AM, Lukas Kahwe Smith m...@pooteeweet.org wrote: On 23.03.2010, at 23:04, Andi Gutmans wrote: What about defining a release manager for the next release? I think that is an important aspect of moving things forward. I also thought the dual RM in PHP 5.3 worked quite well although it is not necessarily a must. Yeah, lets get that clarified. Derick has stepped up and seems quite committed and nobody seemed to oppose him RMing the next release. In case he feels he needs support he can propose a co-RM, after all its important that the two RM's know and trust each other well so that they can speak with a consistent voice. As I think it is still a bit early to design RMs, I am still in favour of David and you. Or David and someone else with good communication skills. You suggested Chris and I think he could do a great job. My only worry is his time availability. But I'm definitively not in favour of Derick, he has been a RM already, let give newer people a chance. 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] trunk is alive and open
At 12:08 24/03/2010, Pierre Joye wrote: Yeah, lets get that clarified. Derick has stepped up and seems quite committed and nobody seemed to oppose him RMing the next release. In case he feels he needs support he can propose a co-RM, after all its important that the two RM's know and trust each other well so that they can speak with a consistent voice. As I think it is still a bit early to design RMs, I am still in favour of David and you. Or David and someone else with good communication skills. You suggested Chris and I think he could do a great job. My only worry is his time availability. But I'm definitively not in favour of Derick, he has been a RM already, let give newer people a chance. FWIW I too want to see you co-RMing. I think you being there, alongside someone else can bring great balance to the release. Zeev -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] trunk is alive and open
On 24.03.2010, at 11:08, Pierre Joye wrote: skills. You suggested Chris and I think he could do a great job. My Just to clarify as I mentioned this on IRC and not on here. I think it would be great to have Chris Jones do the organizational co-RM. For one I have great trust in him keeping a good overview of the priorities, plus he can also give some technical input, where I for example couldn't. Furthermore I was co-RM in the last release, we all know power corrupts so its good to rotate :) For those who might be concerned that he is to embedded at Oracle, I actually think its quite the opposite. I think it would be great for PHP to have him take an official role. I have full trust in his integrity and so it might be also a good signal after the entire PDO2 CLA debacle that we do have trust in working with people from big corps. regards, Lukas Kahwe Smith m...@pooteeweet.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] trunk is alive and open
On Wed, 24 Mar 2010, Lukas Kahwe Smith wrote: On 23.03.2010, at 23:04, Andi Gutmans wrote: What about defining a release manager for the next release? I think that is an important aspect of moving things forward. I also thought the dual RM in PHP 5.3 worked quite well although it is not necessarily a must. Yeah, lets get that clarified. Derick has stepped up and seems quite committed and nobody seemed to oppose him RMing the next release. I'd be happy to do so. In case he feels he needs support he can propose a co-RM, I'd like to do this with David. 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] trunk is alive and open
24.3.2010 12:02, Lukas Kahwe Smith wrote: On 23.03.2010, at 23:04, Andi Gutmans wrote: What about defining a release manager for the next release? I think that is an important aspect of moving things forward. I also thought the dual RM in PHP 5.3 worked quite well although it is not necessarily a must. Yeah, lets get that clarified. Derick has stepped up and seems quite committed and nobody seemed to oppose him RMing the next release. In case he feels he needs support he can propose a co-RM, after all its important that the two RM's know and trust each other well so that they can speak with a consistent voice. Yeah, lets. I'm fine with Derick. IIRC Rasmus also volunteered. Either one of them or both as long as Lukas and Pierre keep their hands off. --Jani -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] trunk is alive and open
On Wed, Mar 24, 2010 at 6:19 PM, Jani Taskinen jani.taski...@sci.fi wrote: 24.3.2010 12:02, Lukas Kahwe Smith wrote: On 23.03.2010, at 23:04, Andi Gutmans wrote: What about defining a release manager for the next release? I think that is an important aspect of moving things forward. I also thought the dual RM in PHP 5.3 worked quite well although it is not necessarily a must. Yeah, lets get that clarified. Derick has stepped up and seems quite committed and nobody seemed to oppose him RMing the next release. In case he feels he needs support he can propose a co-RM, after all its important that the two RM's know and trust each other well so that they can speak with a consistent voice. Yeah, lets. I'm fine with Derick. IIRC Rasmus also volunteered. Either one of them or both as long as Lukas and Pierre keep their hands off. Please keep your pointless comments for yourself, thanks. And to get a clue about what we are talking about may help (or prevent) such stupid comments. One key part of Rasmus comments was: to get the fun back. Your attitude in general actually has the exact opposite effect (and if it was only with me, I could not care less but it is 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
Re: [PHP-DEV] trunk is alive and open
On 2010-03-24, Derick Rethans der...@php.net wrote: On Wed, 24 Mar 2010, Lukas Kahwe Smith wrote: On 23.03.2010, at 23:04, Andi Gutmans wrote: What about defining a release manager for the next release? I think that is an important aspect of moving things forward. I also thought the dual RM in PHP 5.3 worked quite well although it is not necessarily a must. Yeah, lets get that clarified. Derick has stepped up and seems quite committed and nobody seemed to oppose him RMing the next release. I'd be happy to do so. In case he feels he needs support he can propose a co-RM, I'd like to do this with David. Although I can see me doing RM as well (as proposed), I don't think having two tech people as RMs would be good and might result in unecessary discussions during a release phase (for sure there is a benifit splitting work while on rm is not available). I think it is good to have a co-RM that focus on community work. David -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] trunk is alive and open
hi, I would rather have some kind of rules defined before opening trunk again (or the pandora box). That's what we are discussing right now. May I know why you choosed that now is the right time to do it and declare it open? Cheers, On Tue, Mar 23, 2010 at 5:04 PM, Derick Rethans der...@php.net wrote: Hello, I've just created trunk for 5.3 again. I've set the version to 5.3.99-dev as to explicitly not decide on whether there will be 5.4 or 6.0 next. New features should go to trunk; but anything other then trivial additions should require an RFC and discussion. I think Antony has the FPM RFC ready to show what sort of stuff would be useful to have. I'll let Antony start a thread to discuss it (although I doubt there needs to be a lot of discussion for it). I think Ilia mentioned that he wanted to do one more normal 5.2 release, after which it will be security fix only. So for now my suggestion would be: - new features to to trunk - bug fixes go to 5.2 and 5.3. Let's see what cool stuff we can come up with for the next version! with kind regards, 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 -- 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] trunk is alive and open
On 03/23/2010 09:11 AM, Pierre Joye wrote: hi, I would rather have some kind of rules defined before opening trunk again (or the pandora box). That's what we are discussing right now. May I know why you choosed that now is the right time to do it and declare it open? We have rules. Large features, write an RFC and we discuss it. Small and obvious improvements follow commit-then-review as before. We don't need more complicated rules than that. -Rasmus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] trunk is alive and open
On 23.03.2010, at 17:21, Rasmus Lerdorf wrote: On 03/23/2010 09:11 AM, Pierre Joye wrote: hi, I would rather have some kind of rules defined before opening trunk again (or the pandora box). That's what we are discussing right now. May I know why you choosed that now is the right time to do it and declare it open? We have rules. Large features, write an RFC and we discuss it. Small and obvious improvements follow commit-then-review as before. We don't need more complicated rules than that. Yeah, but I still think it would be a good idea to figure out lets say 3-5 big time features that we focus on for the next release and a rough timeline for the next release. For example next major release Q2/Q3 2011: - traits - bundling APC - large file and big number support - ob patch - unicode improvements (*) (*) lets see what ideas we come up with, might turn out to be the big thing or maybe just a small incremental tweak here and there regards, Lukas Kahwe Smith m...@pooteeweet.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] trunk is alive and open
On 03/23/2010 09:32 AM, Pierre Joye wrote: On Tue, Mar 23, 2010 at 5:21 PM, Rasmus Lerdorf ras...@lerdorf.com wrote: On 03/23/2010 09:11 AM, Pierre Joye wrote: hi, I would rather have some kind of rules defined before opening trunk again (or the pandora box). That's what we are discussing right now. May I know why you choosed that now is the right time to do it and declare it open? We have rules. Large features, write an RFC and we discuss it. Small and obvious improvements follow commit-then-review as before. We don't need more complicated rules than that. Right, but what I mean was about releases. But it seems that it is what Derick meant too. trunk remains trunk (development), not a release branch for a hypothetic version. How the next version will be done and when is another discussion. And I tend to agree with you about complex processes. However we do need to drastically improve the way we do or plan releases. It can be done without affecting the way we work, only the way we release and the releases frequency. Releases have nothing to do with this. trunk is where new development happens. Which parts end up in which releases is completely separate from this. Things may be backported to 5.3, or we do a 5.4 release branch off of trunk at some point, or we charge ahead and do a full 6.0 off of trunk. We won't know that until we get some work done in trunk, and the first step is to have an open trunk. -Rasmus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] trunk is alive and open
On Tue, 23 Mar 2010, Derick Rethans wrote: I've just created trunk for 5.3 again. I've set the version to 5.3.99-dev as to explicitly not decide on whether there will be 5.4 or 6.0 next. I've also enabled snapshots for trunk, they are called php-trunk-date.*. See them at http://snaps.php.net/ regards, 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] trunk is alive and open
On 23 March 2010 16:38, Derick Rethans der...@php.net wrote: On Tue, 23 Mar 2010, Derick Rethans wrote: I've just created trunk for 5.3 again. I've set the version to 5.3.99-dev as to explicitly not decide on whether there will be 5.4 or 6.0 next. I've also enabled snapshots for trunk, they are called php-trunk-date.*. See them at http://snaps.php.net/ regards, 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 Are the win32 snapshots going to come back online again? Re:http://bugs.php.net/bug.php?id=50821 Regards, Richard. -- - Richard Quadling Standing on the shoulders of some very clever giants! EE : http://www.experts-exchange.com/M_248814.html EE4Free : http://www.experts-exchange.com/becomeAnExpert.jsp Zend Certified Engineer : http://zend.com/zce.php?c=ZEND002498r=213474731 ZOPA : http://uk.zopa.com/member/RQuadling -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] trunk is alive and open
On 03/23/2010 09:36 AM, Lukas Kahwe Smith wrote: On 23.03.2010, at 17:21, Rasmus Lerdorf wrote: On 03/23/2010 09:11 AM, Pierre Joye wrote: hi, I would rather have some kind of rules defined before opening trunk again (or the pandora box). That's what we are discussing right now. May I know why you choosed that now is the right time to do it and declare it open? We have rules. Large features, write an RFC and we discuss it. Small and obvious improvements follow commit-then-review as before. We don't need more complicated rules than that. Yeah, but I still think it would be a good idea to figure out lets say 3-5 big time features that we focus on for the next release and a rough timeline for the next release. For example next major release Q2/Q3 2011: - traits - bundling APC - large file and big number support - ob patch - unicode improvements (*) (*) lets see what ideas we come up with, might turn out to be the big thing or maybe just a small incremental tweak here and there We don't need timelines right now. What we need is some hacking time and to bring some fun back into PHP development. It hasn't been fun for quite a while. Once we have a body of new interesting stuff, we can start pondering releases with a release branch off of trunk that might cherry-pick a subset of the work in trunk and you can start making your lists and setting timelines at that point. -Rasmus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] trunk is alive and open
On 03/23/2010 10:05 AM, Lukas Kahwe Smith wrote: On 23.03.2010, at 17:59, Rasmus Lerdorf wrote: On 03/23/2010 09:36 AM, Lukas Kahwe Smith wrote: On 23.03.2010, at 17:21, Rasmus Lerdorf wrote: On 03/23/2010 09:11 AM, Pierre Joye wrote: hi, I would rather have some kind of rules defined before opening trunk again (or the pandora box). That's what we are discussing right now. May I know why you choosed that now is the right time to do it and declare it open? We have rules. Large features, write an RFC and we discuss it. Small and obvious improvements follow commit-then-review as before. We don't need more complicated rules than that. Yeah, but I still think it would be a good idea to figure out lets say 3-5 big time features that we focus on for the next release and a rough timeline for the next release. For example next major release Q2/Q3 2011: - traits - bundling APC - large file and big number support - ob patch - unicode improvements (*) (*) lets see what ideas we come up with, might turn out to be the big thing or maybe just a small incremental tweak here and there We don't need timelines right now. What we need is some hacking time and to bring some fun back into PHP development. It hasn't been fun for quite a while. Once we have a body of new interesting stuff, we can start pondering releases with a release branch off of trunk that might cherry-pick a subset of the work in trunk and you can start making your lists and setting timelines at that point. Well .. as you can see from the above list, this is already a backlog of fun stuff that is pretty far along. This is why I am saying lets get to a release often cycle, where people can work on stuff and be sure to get it in at a reasonable timeframe and also prevent stuff like PHP6/PHP5.3 from happening again. And since we are talking about cherry picking features from trunk into the next release branch (along with feature branches), we are back to a situation where fun hacking can always happen. But imho we have enough features on the table that we can start cherry picking now ... of course we can still fast track other stuff later on .. but its also not that bad that after a release we already have a full pipeline to plan the next release. Until someone does the work and commits code to trunk complete with working tests we don't have anything except a list of theoretical features. We don't know if any of the things on your list are actually feasible yet giving the level of interest from the various people behind those items. I know for APC, for example, both Gopal and Brian Shire are off doing other things right now, so we may not be able to get that list item integrated anytime soon, if ever. What is the current state of the traits patch? We have 2 different large number approaches. Those guys need to write their rfcs and compare notes. The ob patch seems close, but it breaks on some operating systems, so unless someone has time to look into that, that one isn't feasible either. And we may end up seeing a number of other interesting and complete patches pop up. My point is that your eventual list should come from things that have been committed to trunk and survived review and tests. -Rasmus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] trunk is alive and open
Hi Derick 2010/3/23 Derick Rethans der...@php.net: Hello, I've just created trunk for 5.3 again. I've set the version to 5.3.99-dev as to explicitly not decide on whether there will be 5.4 or 6.0 next. Great! New features should go to trunk; but anything other then trivial additions should require an RFC and discussion. I think Antony has the FPM RFC ready to show what sort of stuff would be useful to have. I'll let Antony start a thread to discuss it (although I doubt there needs to be a lot of discussion for it). Im assuming that we are still removing the stuff that we deprecated in 5.3 and removed in the old trunk? If thats the case then I will work on merging those removed features like safe_mode and so on out. -- regards, Kalle Sommer Nielsen ka...@php.net -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] trunk is alive and open
New features should go to trunk; but anything other then trivial additions should require an RFC and discussion. I think Antony has the FPM RFC ready to show what sort of stuff would be useful to have. I'll let Antony start a thread to discuss it (although I doubt there needs to be a lot of discussion for it). Im assuming that we are still removing the stuff that we deprecated in 5.3 and removed in the old trunk? If thats the case then I will work on merging those removed features like safe_mode and so on out. no please wait, if it's a 6.0 then probably yes, if it's a 5.4 then probably no. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] trunk is alive and open
Hi, On Tue, 2010-03-23 at 18:44 +0100, Kalle Sommer Nielsen wrote: Im assuming that we are still removing the stuff that we deprecated in 5.3 and removed in the old trunk? If thats the case then I will work on merging those removed features like safe_mode and so on out. I think that's, like other stuff, a case-by-case decision. For example I don't think it's a good idea to drop magic_quotes in a version which doesn't include a big BC break. Unfortunately many applications are half-secure by this setting but absolutely insecure once that's changed and people update without reading docs - especially if a quick test shows no errors. With finally dropping register_globals I won't have problems. johannes -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] trunk is alive and open
On Tue, 2010-03-23 at 16:04 +, Derick Rethans wrote: Hello, I've just created trunk for 5.3 again. I've set the version to 5.3.99-dev as to explicitly not decide on whether there will be 5.4 or 6.0 next. As I mentioned on IRC and in previous threads: I'd prefer to call it 5.4 - we can still increase the number as needed but we will almost certainly break ABIs/APIs and need to change API no.s and changing the second digit might reduce some confusion by bug reporters ... johannes -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] trunk is alive and open
Hi: On 23 Mar 2010, at 18:15, Rasmus Lerdorf wrote: On 03/23/2010 09:36 AM, Lukas Kahwe Smith wrote: Yeah, but I still think it would be a good idea to figure out lets say 3-5 big time features that we focus on for the next release and a rough timeline for the next release. For example next major release Q2/Q3 2011: - traits What is the current state of the traits patch? We have 2 different large number approaches. Those guys need to write their rfcs and compare notes. As far as I am concerned, traits, as proposed in the RFC[1], are implemented and it would be possible to merge them in. However, as far as I remember, there was no consensus on several details of this proposal. So, what I can do is to ask you guys to reread the proposal and checkout a copy from [2] to look for instance at the test cases, and tell me what you don't like. Best regards Stefan [1] http://wiki.php.net/rfc/horizontalreuse [2] http://github.com/gron/php-src/tree/PHP_5_3-traits -- Stefan Marr Software Languages Lab Vrije Universiteit Brussel Pleinlaan 2 / B-1050 Brussels / Belgium http://soft.vub.ac.be/~smarr Phone: +32 2 629 2974 Fax: +32 2 629 3525 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] trunk is alive and open
-Original Message- From: Derick Rethans [mailto:der...@php.net] Sent: Tuesday, March 23, 2010 9:05 AM To: PHP Developers Mailing List Subject: [PHP-DEV] trunk is alive and open Hello, I've just created trunk for 5.3 again. I've set the version to 5.3.99-dev as to explicitly not decide on whether there will be 5.4 or 6.0 next. New features should go to trunk; but anything other then trivial additions should require an RFC and discussion. I think Antony has the FPM RFC ready to show what sort of stuff would be useful to have. I'll let Antony start a thread to discuss it (although I doubt there needs to be a lot of discussion for it). I think Ilia mentioned that he wanted to do one more normal 5.2 release, after which it will be security fix only. So for now my suggestion would be: - new features to to trunk - bug fixes go to 5.2 and 5.3. Let's see what cool stuff we can come up with for the next version! What about defining a release manager for the next release? I think that is an important aspect of moving things forward. I also thought the dual RM in PHP 5.3 worked quite well although it is not necessarily a must. I do think we want to avoid ending up with another stale trunk. As I mentioned in my previous note it's important to have a reasonable scope for the next upcoming major (5.4/6.0) release and make sure we do have the right amount of discussions re: new functionality committed. So I do propose that in the coming weeks (as 80% of the ideas surface) the RMs create a roadmap for the next version which clearly identifies the must-haves and should-haves. This can always be changed/tweaked (as we always have in the past) but it sets the tone for pushing out functionality sooner rather than later (i.e. if a should-have is still not quite fully baked but all must-haves are done then ship). As we saw with PHP 5.3 it ended up being a pretty major version and it delivers a lot of incremental value. So it was good it didn't wait for every single idea. Andi -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] trunk is alive and open
On 23.03.2010, at 18:15, Rasmus Lerdorf wrote: My point is that your eventual list should come from things that have been committed to trunk and survived review and tests. Sure, its only that many patches and todo items have been lingering (hello frustration?) because of the trunk situation, because we decided to then focus on 5.3 etc. Stuff like traits, the OB fixes have been flying around for a long time and just didnt get the last attention. LFS and big ints have also been on the roadmap for ages and it seems like at least for big numbers there is even a patch. If we now spend a few months to work on fun stuff (which is what we have trunk for) instead of focusing on getting this stuff finalized we are just delaying these patches. We all know that when we get towards crunch time we finalize patches way more quickly, than when we say oh lets hack on stuff for a while and see where we get. Again, for fun development there is trunk or feature branches. But we have enough stuff for a new major release right at our finger tips to start thinking about what our next release should look like instead of waiting for another 3-6 months which would obviously also imply a delay of at least 6-9 months (because big new features we come up with in the next 3-6 months will need their time to make it into trunk as well). So sure lets take until the end of April to think about a set of patches we want, but please lets not spend the next 3-6 months coming up with entirely new ideas to put into the next major update. Then again this might just be a misunderstanding and you are also just talking about giving some key features a few weeks to make it into trunk and in a state where we feel fairly certain that we can fix any issues should there still be any. In conclusion: There should of course be fun in just hacking out cool stuff, but I think for most developers a big part of the fun is actually seeing your ideas in a stable release. regards, Lukas Kahwe Smith m...@pooteeweet.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] trunk is alive and open
On 03/23/2010 04:02 PM, Lukas Kahwe Smith wrote: In conclusion: There should of course be fun in just hacking out cool stuff, but I think for most developers a big part of the fun is actually seeing your ideas in a stable release. Exactly. But that means we need to wait and see which developers step up and actually commit their code to trunk. You can create all the shopping lists you want and set all the dates you want, but they are irrelevant until we see some of this stuff hashed out via rfcs and then reviewed once actually committed to trunk. PHP development stalled in large part because we had lists of features without developers passionate about those features. So, less lists, and more coding for a while, please. We've got 2 small commits to trunk so far. I switched our default charset from ISO-8859-1 to UTF-8, and Michael added FNV hashing. Both minor changes, but we need to encourage more of these smaller incremental improvements in the dev branch and not discourage them because they weren't on a list somewhere before a certain date. Release dates slide because of a lack of developers, not because we have too many people committing stuff. Having a lot of people committing code is a good problem to have and the release manager(s) will sort it out eventually. -Rasmus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
