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
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
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/
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
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
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
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
-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
+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
+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
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
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
+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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
-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
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
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
50 matches
Mail list logo
