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
2010/4/30 Gwynne Raskind :
> 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
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:
>>>&g
d; 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:
>>>> Bef
h; 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
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/
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 waite
ing 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
+1 For derick and Kalle
2010/4/27 Kalle Sommer Nielsen :
> Hi
>
> 2010/3/24 Lukas Kahwe Smith :
>> 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
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
whene
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 wrote:
> +1 for Derick and Kalle, and +1 for alpha by Q4.
>
> On Apr 27, 2010, at 8:53 AM,
+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 wrote:
>> Hi
>>
>> 2010/3/24 Lukas Kahwe Smith :
>>> Yeah, lets get that clarified. Derick has ste
+1 for a co-RM of Derick and Kalle
On Tue, Apr 27, 2010 at 12:33 AM, Kalle Sommer Nielsen wrote:
> Hi
>
> 2010/3/24 Lukas Kahwe Smith :
> > 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 h
Hi
2010/3/24 Lukas Kahwe Smith :
> 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
On 2010-03-24, David Soria Parra wrote:
> On 2010-03-24, Derick Rethans 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
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 t
2010/3/31 Philip Olson :
> 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://w
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 lov
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
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 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
On Sat, Mar 27, 2010 at 11:12 AM, Lukas Kahwe Smith wrote:
>
> 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 sh
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 happ
On 2010-03-25, Christopher Jones 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.
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
On 2010-03-24, Derick Rethans 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
>>
On Wed, Mar 24, 2010 at 6:19 PM, Jani Taskinen 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 t
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 no
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
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
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 eac
hi,
On Wed, Mar 24, 2010 at 11:02 AM, 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 w
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 clarif
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 de
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 situatio
> -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'v
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.
>
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
- w
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
>> 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
On 23.03.2010, at 18:44, Kalle Sommer Nielsen wrote:
> Hi Derick
>
> 2010/3/23 Derick Rethans :
>> 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 usefu
Hi Derick
2010/3/23 Derick Rethans :
> 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 req
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
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
a
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 rig
yes
On Tue, Mar 23, 2010 at 5:47 PM, Richard Quadling
wrote:
> On 23 March 2010 16:38, Derick Rethans 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
On 23 March 2010 16:38, Derick Rethans 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
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-.*. See them at http://snaps.php.ne
On 03/23/2010 09:32 AM, Pierre Joye wrote:
> On Tue, Mar 23, 2010 at 5:21 PM, 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
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
On Tue, Mar 23, 2010 at 5:21 PM, 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
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. L
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 wrote:
> Hello
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 R
54 matches
Mail list logo