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
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,
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,
Derickhttp://derickrethans.nl | http://xdebug.org
Like Xdebug? Consider a donation: http://xdebug.org/donate.php
twitter: @derickr and @xdebug--
--
Pierre
@pierrejoye | http://blog.thepimp.net | http://www.libgd.org
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
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.
Cheers,
Pierre
@pierrejoye | http://blog.thepimp.net | http://www.libgd.org
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
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
mls@pooteeweet.org
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
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.
regards,
Lukas Kahwe Smith
mls@pooteeweet.org
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
Hi:
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
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
mls@pooteeweet.org
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
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
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--
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=ZEND002498&r=213474731
ZOPA : http://uk.zopa.com/member/RQuadling
yes
On Tue, Mar 23, 2010 at 5:47 PM, Richard Quadling
rquadling@googlemail.com 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--
Are the win32 snapshots going to come back online again?
Re:http://bugs.php.net/bug.php?id=50821Regards,
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=ZEND002498&r=213474731
ZOPA : http://uk.zopa.com/member/RQuadling--
--
Pierre
@pierrejoye | http://blog.thepimp.net | http://www.libgd.org
Hi Derick
2010/3/23 Derick Rethans derick@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
kalle@php.net
Hi Derick
2010/3/23 Derick Rethans derick@php.net:
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.
uhm no .. i think for that stuff we have to wait until we decide if the next version is 6.0 or 5.4
regards,
Lukas Kahwe Smith
mls@pooteeweet.org
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.
Hi,
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
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
-----Original Message-----
From: Derick Rethans [mailto:derick@php.net]
Sent: Tuesday, March 23, 2010 9:05 AM
To: PHP Developers Mailing List
Subject: [PHP-DEV] trunk is alive and openHello,
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
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
mls@pooteeweet.org
hi,
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
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
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
mls@pooteeweet.org
Lukas Kahwe Smith 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
mls@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.jones@oracle.com
Tel: +1 650 506 8630
Blog: http://blogs.oracle.com/opal/
Free PHP Book: http://tinyurl.com/ugpomhome
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.
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
mls@pooteeweet.org
On Sat, Mar 27, 2010 at 11:12 AM, Lukas Kahwe Smith mls@pooteeweet.orgwrote:
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
mls@pooteeweet.org--
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
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
hi florian,
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
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
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
2010/3/31 Philip Olson philip@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
kalle@php.net
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
Hi all,
I have been following the internals list since I heard that the unicode effort had grinded to a halt (so I am quite the noob into the php internals world).
I have some ideas for possible ways to implement unicode handling. My guess is that most of these have been discussed earlier but I do not seem to be able to find any good way of reading up on the choices that led to the php 6 unicode implementation (please direct me in the right direction if such a source is available). It would also be great if there was a source of information that listed some of the caveats of the project that I am guessing is what is making it hard to implement.
I proppose that we make a wiki page that attempts to summarize information about unicode support in php. Some of the headlines on the page could be:
- Desired features
- Cavets
- The "php 6 way"
- Possible alternative "ways"
I think this would give a good overview that would make it easier to make the right decision on how to move forward.
I would like to organize/collect/manage the information, but I need help in finding the needed information.
Is this a good idea?
Is it silly to have someone, that has not been involved in the earlier unicode discussions, trying to summarize on them?
Regards, Jacob Oettinger
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
mls@pooteeweet.org
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
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
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
24.3.2010 12:02, Lukas Kahwe Smith 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
24.3.2010 12:02, Lukas Kahwe Smith 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
Hi
2010/3/24 Lukas Kahwe Smith mls@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
kalle@php.net
+1 for a co-RM of Derick and Kalle
On Tue, Apr 27, 2010 at 12:33 AM, Kalle Sommer Nielsen kalle@php.netwrote:
Hi
2010/3/24 Lukas Kahwe Smith mls@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
kalle@php.net
+1 for Derick and Kalle, and +1 for alpha by Q4.
+1 for a co-RM of Derick and Kalle
On Tue, Apr 27, 2010 at 12:33 AM, Kalle Sommer Nielsen kalle@php.netwrote:
Hi
2010/3/24 Lukas Kahwe Smith mls@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
kalle@php.net
-- Gwynne
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,
+1 for Derick and Kalle, and +1 for alpha by Q4.
+1 for a co-RM of Derick and Kalle
On Tue, Apr 27, 2010 at 12:33 AM, Kalle Sommer Nielsen kalle@php.netwrote:
Hi
2010/3/24 Lukas Kahwe Smith mls@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
kalle@php.net-- Gwynne
--
--
Pierre
@pierrejoye | http://blog.thepimp.net | http://www.libgd.org
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
-----Original Message-----
From: Johannes Schlüter [mailto:johannes@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 openBefore 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
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.
brianlmoon@php.net
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 Bergmann Co-Founder and Principal Consultant
http://sebastian-bergmann.de/ http://thePHP.cc/
2010/4/29 Andi Gutmans andi@zend.com:
-----Original Message-----
From: Johannes Schlüter [mailto:johannes@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 openBefore 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
2010/4/29 Andi Gutmans andi@zend.com:
-----Original Message-----
From: Johannes Schlüter [mailto:johannes@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 openBefore 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
mls@pooteeweet.org
-----Original Message-----
From: Johannes Schlüter [mailto:johannes@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 openBefore 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
2010/4/30 Gwynne Raskind gwynne@darkrainfall.org:
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.
+1 For derick and Kalle
2010/4/27 Kalle Sommer Nielsen kalle@php.net:
Hi
2010/3/24 Lukas Kahwe Smith mls@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
kalle@php.net