Hi Internals
It's already mid-october and according to our release schedule we have to
release PHP 5.6 in 10 months from now. The past has shown that we need
approx 5 months to stablize a release and go through alpha, beta and RC
stages. Therefore I want to start a discussion on how to move forward
with 5.6, to get a release schedule up as fast as possible so contributors
now when to push their stuff and to vote on RFC's BEFORE the first beta.
I think over the last years it proved to be good to have the current
RM support a new RM who then takes over after the final release
(e.g. Julien basically does 5.5 alone now, but we worked a lot together
during alpha/beta/RC). Therefore my suggestion is that Julien is going to
help out with 5.6 and then we would need a new RM that can learn from julien
on how to do things to later be able to do 5.6 on his own.
Suggestions?
David
Hi Internals
It's already mid-october and according to our release schedule we have to
release PHP 5.6 in 10 months from now. The past has shown that we need
approx 5 months to stablize a release and go through alpha, beta and RC
stages. Therefore I want to start a discussion on how to move forward
with 5.6, to get a release schedule up as fast as possible so contributors
now when to push their stuff and to vote on RFC's BEFORE the first beta.I think over the last years it proved to be good to have the current
RM support a new RM who then takes over after the final release
(e.g. Julien basically does 5.5 alone now, but we worked a lot together
during alpha/beta/RC). Therefore my suggestion is that Julien is going to
help out with 5.6 and then we would need a new RM that can learn from
julien
on how to do things to later be able to do 5.6 on his own.Suggestions?
David
--
I agree with all of the points above.
I also think that we could be a bit more pro-active with the already
presented RFCs and try to bug the authors or chip in with the
implementation so that we don't end up in a situation where every new
language construct comes in at the last minute (before or even after the
feature freeze).
I also think that not that many people familiar with what exactly an RM
does, so I think (hope) that the lack of volunteers/candidates for RMing
was caused by the fact that most people don't know what are the
requirements for being an RM.
From my understanding it is a little bit of project management and
resolving some disputes whether or not some feature should be
approved/rejected(usually you just point to
https://wiki.php.net/rfc/releaseprocess RFC), but most of the times it is
just following
http://git.php.net/?p=php-src.git;a=blob_plain;f=README.RELEASE_PROCESS, so
tagging/packaging the release, writing the release announcement, etc.
Personally I would propose Nikic to the post, but I would also happy if
Johannes or Stas would be a returning RM for the 5.6 release.
--
Ferenc Kovács
@Tyr43l - http://tyrael.hu
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
From my understanding it is a little bit of project management and
resolving some disputes whether or not some feature should be
approved/rejected(usually you just point to
https://wiki.php.net/rfc/releaseprocess RFC), but most of the times
it is just following
http://git.php.net/?p=php-src.git;a=blob_plain;f=README.RELEASE_PROCESS,
so tagging/packaging the release, writing the release announcement, etc.
It is mostly project managing and QA. During alpha/beta phase it is
manging and creating lists of things that need to be done and asking
the people to do it as well as keeping and eye on RFC discussions, etc.
During beta/RC it is checking that nobody is adding new features, etc
and judging if the current implemented features are mature enough to
be kept (but don't mistaken this as a decision as to "what" goes it,
that's RFCs + votes). In the end it's your responsibility to release a
mature software that can be deployed by millions of people. Once
released your main job as an RM is to keep an eye on security related
bugs and follow the release process as much as possible. It's also a
lot of talking to other RMs in order to release bugfixes, etc
together, ensure we have a CVE, ensure that announcments are correct, etc.
So it's just managing and checking that people do follow RFCs and that
the project itself is following the release process rfc.
David
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.15 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQIcBAEBAgAGBQJSXVUmAAoJEKSanlo0ToXKY18P/0y5GyLz5q1ypzuF0MrJfsmK
8/Ug5X5f7fzdw3w01YI+VB3slsp9U5nkcb1FDvflmjyXkVESLSGQTqw6jPQ4pXS7
YKVxRdIhvvjk/UGIivAjBJ+mYUvJCVHC1TkXSQJVMBsahxADCHN1W+Lkr2PngYAD
5r/o/bimpBdf3EiWo62C7DenLjB0H5mLVwCqYktz3rdXiuKDFwHcMAgpAr5hl/nA
zaiQl1ikdYTfaxz8IBOxjyVyoxbHd5EQHGnW6+GpnikYIcDZHHHaBpcedFEJ1ac/
4hUpYHefGVsOAC9ZEbJlPM2r2IZkC/l4Sa5b1LMAlIC4wAA/6EOJRKeeZKJcsOG7
jbKsPiE9yDzA8HZQLjkX1MwlINHi5RFOwdK3epDj1m0ks8EpDxuFJSKyULqKtqoh
mQ76TQTPeJjRxN3qKASq9RxR0HnkUIHr1P+M2TcEU257IBztWgVQDVnne1pm0/e2
CNqRFjk8NZGnwkuYllD7SHApY9vY5UwdUBMs2LW39XZ2SSDHBrAkv7Igd3VK+PUJ
/MD6PsgLSxLsR13SxXowcNjIvoiGEYw2h92G7Q7zqfgeIu7PvxpCEVI2fOpOvV+k
DEebtqDfDutImTzr7S5f/FDNq82p3c5dtKQXWOH+QNFUmecsASzlypY0S6qIQgRY
6FrnvieqM6nQOewUSRto
=x02p
-----END PGP SIGNATURE
Hi Internals
It's already mid-october and according to our release schedule we have to
release PHP 5.6 in 10 months from now. The past has shown that we need
approx 5 months to stablize a release and go through alpha, beta and RC
stages. Therefore I want to start a discussion on how to move forward
with 5.6, to get a release schedule up as fast as possible so contributors
now when to push their stuff and to vote on RFC's BEFORE the first beta.I think over the last years it proved to be good to have the current
RM support a new RM who then takes over after the final release
(e.g. Julien basically does 5.5 alone now, but we worked a lot together
during alpha/beta/RC). Therefore my suggestion is that Julien is going to
help out with 5.6 and then we would need a new RM that can learn from
julien
on how to do things to later be able to do 5.6 on his own.
I'm OK to work together with our future 5.6 RM :-)
Let's start finding someone then
Julien.Pauli
hi David,
Hi Internals
It's already mid-october and according to our release schedule we have to
release PHP 5.6 in 10 months from now. The past has shown that we need
approx 5 months to stablize a release and go through alpha, beta and RC
stages. Therefore I want to start a discussion on how to move forward
with 5.6, to get a release schedule up as fast as possible so contributors
now when to push their stuff and to vote on RFC's BEFORE the first beta.
I will add some of the known TODOs to https://wiki.php.net/todo/php56
in the next couple of days.
I think over the last years it proved to be good to have the current
RM support a new RM who then takes over after the final release
(e.g. Julien basically does 5.5 alone now, but we worked a lot together
during alpha/beta/RC). Therefore my suggestion is that Julien is going to
help out with 5.6 and then we would need a new RM that can learn from julien
on how to do things to later be able to do 5.6 on his own.Suggestions?
I can do it if necessary, we (ostc team) are part of it anyway from a
QA and windows point of view.
Cheers,
Pierre
@pierrejoye | http://www.libgd.org
Hi Inf^Hternals,
Debian freeze will happen in 14 months, that means that we might be able
to squeeze PHP 5.6 into next Debian stable.
One question though – do you envision that the module ABI will change in
PHP 5.6? (e.g. are there already plans to do so?) Obviously not
changing ABI would make things much more simpler since it won't require
the transition. Knowing before hand would also making things simpler
since I could get pre-approval from Debian release team.
Ondrej
Ondřej Surý ondrej@sury.org
Knot DNS (https://www.knot-dns.cz/) – a high-performance DNS server
Hi Internals
It's already mid-october and according to our release schedule we have to
release PHP 5.6 in 10 months from now. The past has shown that we need
approx 5 months to stablize a release and go through alpha, beta and RC
stages. Therefore I want to start a discussion on how to move forward
with 5.6, to get a release schedule up as fast as possible so
contributors
now when to push their stuff and to vote on RFC's BEFORE the first beta.I think over the last years it proved to be good to have the current
RM support a new RM who then takes over after the final release
(e.g. Julien basically does 5.5 alone now, but we worked a lot together
during alpha/beta/RC). Therefore my suggestion is that Julien is going to
help out with 5.6 and then we would need a new RM that can learn from
julien
on how to do things to later be able to do 5.6 on his own.Suggestions?
David
hi Ondřej!
Hi Inf^Hternals,
Debian freeze will happen in 14 months, that means that we might be able
to squeeze PHP 5.6 into next Debian stable.One question though – do you envision that the module ABI will change in
PHP 5.6? (e.g. are there already plans to do so?) Obviously not
changing ABI would make things much more simpler since it won't require
the transition. Knowing before hand would also making things simpler
since I could get pre-approval from Debian release team.
We surely may change it yes. Mainly due to better 64bit support,
size_t and int(32|64)_t usage. That will impact a lot of code, in core
or in external extensions. Help welcome in this area as it is a huge
effort.
Some remaining missing TSRMLS_* usage may be added as well.
Cheers,
Pierre
@pierrejoye | http://www.libgd.org
Hi Inf^Hternals,
Debian freeze will happen in 14 months, that means that we might be able
to squeeze PHP 5.6 into next Debian stable.One question though – do you envision that the module ABI will change in
PHP 5.6? (e.g. are there already plans to do so?) Obviously not
changing ABI would make things much more simpler since it won't require
the transition. Knowing before hand would also making things simpler
since I could get pre-approval from Debian release team.
Yes, chances are good that it won't be ABI compatible. I don't think we
have ever had a X.Y relased that was completely ABI compatible with X.Y-1.
-Rasmus
David Soria Parra dsp@php.net schrieb:
I think over the last years it proved to be good to have the current
RM support a new RM who then takes over after the final release
(e.g. Julien basically does 5.5 alone now, but we worked a lot together
during alpha/beta/RC). Therefore my suggestion is that Julien is going to
help out with 5.6 and then we would need a new RM that can learn from julien
on how to do things to later be able to do 5.6 on his own.
So I mabe think Ferenic (tyrael) would be a good RM. He has been involved
with the project for the last 3 years and knows the community, the code
and infrastrucutre well. He followed the RFC process and knows most of the
core devs in order to be able to manage them good. Indeed he hasn't hacked
on the Zend Engine itself, but I think together with Julien he probably
do a fine job. suggestions?
David
David Soria Parra dsp@php.net schrieb:
I think over the last years it proved to be good to have the current
RM support a new RM who then takes over after the final release
(e.g. Julien basically does 5.5 alone now, but we worked a lot together
during alpha/beta/RC). Therefore my suggestion is that Julien is going to
help out with 5.6 and then we would need a new RM that can learn from
julien
on how to do things to later be able to do 5.6 on his own.So I mabe think Ferenic (tyrael) would be a good RM. He has been involved
with the project for the last 3 years and knows the community, the code
and infrastrucutre well. He followed the RFC process and knows most of the
core devs in order to be able to manage them good. Indeed he hasn't hacked
on the Zend Engine itself, but I think together with Julien he probably
do a fine job. suggestions?Yep, Ferenic and myself usually agree together, and we already have
performed complementary tasks :-)
I'm all +1 for Ferenic (tyrael)
Julien
David Soria Parra dsp@php.net schrieb:
I think over the last years it proved to be good to have the current
RM support a new RM who then takes over after the final release
(e.g. Julien basically does 5.5 alone now, but we worked a lot together
during alpha/beta/RC). Therefore my suggestion is that Julien is going to
help out with 5.6 and then we would need a new RM that can learn from
julien
on how to do things to later be able to do 5.6 on his own.So I mabe think Ferenic (tyrael) would be a good RM. He has been involved
with the project for the last 3 years and knows the community, the code
and infrastrucutre well. He followed the RFC process and knows most of the
core devs in order to be able to manage them good. Indeed he hasn't hacked
on the Zend Engine itself, but I think together with Julien he probably
do a fine job. suggestions?Yep, Ferenic and myself usually agree together, and we already have
performed complementary tasks :-)
I'm all +1 for Ferenic (tyrael)Julien
+1 for Ferenc Kovacs. (is it a voting thread? :D)
--
Regards,
Felipe Pena
+1 for Ferenc Kovacs. (is it a voting thread? :D)
+1 (let's make it a good ol' one :))
--
Regards,
Mike
+1 for Ferenc Kovacs. (is it a voting thread? :D)
+1 (let's make it a good ol' one :))
+1 for both
--
Pierre
@pierrejoye | http://www.libgd.org
+1 for Ferenc Kovacs. (is it a voting thread? :D)
+1 (let's make it a good ol' one :))
+1 for both
--
Pierre@pierrejoye | http://www.libgd.org
--
Hi,
thank you guys for the support, it means a lot!
--
Ferenc Kovács
@Tyr43l - http://tyrael.hu
+1 for Ferenc Kovacs. (is it a voting thread? :D)
+1 (let's make it a good ol' one :))
+1 for both
--
Pierre@pierrejoye | http://www.libgd.org
--
Hi,
thank you guys for the support, it means a lot!
+1.
Chris
--
christopher.jones@oracle.com http://twitter.com/ghrd
Free PHP & Oracle book:
http://www.oracle.com/technetwork/topics/php/underground-php-oracle-manual-098250.html
+1 for Ferenc Kovacs. (is it a voting thread? :D)
+1 (let's make it a good ol' one :))
Not that I'm objecting, but I think it would probably a good idea (for
next time) to have an RFC style vote (with "VOTE" in the subject) with
perhaps different options for this?
cheers,
Derick
+1 for Ferenc Kovacs. (is it a voting thread? :D)
+1 (let's make it a good ol' one :))
Not that I'm objecting, but I think it would probably a good idea (for
next time) to have an RFC style vote (with "VOTE" in the subject) with
perhaps different options for this?cheers,
Derick--
+1 for having some kind of official process for this.
--
Ferenc Kovács
@Tyr43l - http://tyrael.hu
David Soria Parra dsp@php.net schrieb:
I think over the last years it proved to be good to have the current
RM support a new RM who then takes over after the final release
(e.g. Julien basically does 5.5 alone now, but we worked a lot together
during alpha/beta/RC). Therefore my suggestion is that Julien is going to
help out with 5.6 and then we would need a new RM that can learn from
julien
on how to do things to later be able to do 5.6 on his own.So I mabe think Ferenic (tyrael) would be a good RM.
I'm all for that as well :)
+1
On Wed, Oct 23, 2013 at 8:57 PM, Sherif Ramadan theanomaly.is@gmail.comwrote:
David Soria Parra dsp@php.net schrieb:
I think over the last years it proved to be good to have the current
RM support a new RM who then takes over after the final release
(e.g. Julien basically does 5.5 alone now, but we worked a lot together
during alpha/beta/RC). Therefore my suggestion is that Julien is going
to
help out with 5.6 and then we would need a new RM that can learn from
julien
on how to do things to later be able to do 5.6 on his own.So I mabe think Ferenic (tyrael) would be a good RM.
I'm all for that as well :)
+1
Hi back !
I suggest we move forward on the topic.
We're gonna enter November soon, this is a dead line to branch 5.6.
I suggest we branch 5.6 from master, then run the 5.5 test suite against
the branch, and remove every commit that leads to a BC break.
The task shouldn't be too hard.
When the branch is created, the wiki then would have to be updated to show
the ideas we'd like to support (https://wiki.php.net/todo/php56)
Julien Pauli
On Wed, Oct 23, 2013 at 8:57 PM, Sherif Ramadan <theanomaly.is@gmail.com
wrote:
David Soria Parra dsp@php.net schrieb:
I think over the last years it proved to be good to have the current
RM support a new RM who then takes over after the final release
(e.g. Julien basically does 5.5 alone now, but we worked a lot
together
during alpha/beta/RC). Therefore my suggestion is that Julien is
going
to
help out with 5.6 and then we would need a new RM that can learn from
julien
on how to do things to later be able to do 5.6 on his own.So I mabe think Ferenic (tyrael) would be a good RM.
I'm all for that as well :)
+1
Hi back !
I suggest we move forward on the topic.
We're gonna enter November soon, this is a dead line to branch 5.6.
I suggest we branch 5.6 from master, then run the 5.5 test suite against
the branch, and remove every commit that leads to a BC break.
The task shouldn't be too hard.When the branch is created, the wiki then would have to be updated to show
the ideas we'd like to support (https://wiki.php.net/todo/php56)Julien Pauli
Hi,
I was working on that last week, there are a couple of test related changes
which should/could be backported to 5.5 (and maybe even 5.4):
http://git.php.net/?p=php-src.git;a=commitdiff;h=ecbe4af0de94c629fa5ba8ab169654e00c958bad
http://git.php.net/?p=php-src.git;a=commitdiff;h=361e984e462de5422bba5470d3961e67de327396
http://git.php.net/?p=php-src.git;a=commitdiff;h=95017c0522a9a1b9527d7cc1d866fbc3b89df7ac
I have sent an email to Sara/ptarjan, but got no response yet:
http://permalink.gmane.org/gmane.comp.php.cvs.general/62834
The sole BC break I've found yet was the removal of $HTTP_RAW_POST_DATA and
co from Mike:
http://git.php.net/?p=php-src.git;a=commitdiff;h=423c70fb4d79b7831b1db41ea217c8e1afd5cf8e
http://git.php.net/?p=php-src.git;a=commitdiff;h=449d4c0b1c6ea0f5dfe7b56c99d9fc4f2033d27c
http://git.php.net/?p=php-src.git;a=commitdiff;h=4a3936ef4abdeb72c7d323fe4b6a65e1ae0ef181
http://git.php.net/?p=php-src.git;a=commitdiff;h=8d087dc0d7c88e26539646875dc0f7bb5042187b
This would be a measurable improvement for many of our users with a
relatively easy way to restore/emulate the old behavior
($HTTP_RAW_POST_DATA = file_get_contents("php://input");) so maybe it
should be worth a discussion whether or not we should revert it from 5.6.
--
Ferenc Kovács
@Tyr43l - http://tyrael.hu
On Wed, Oct 23, 2013 at 8:57 PM, Sherif Ramadan <theanomaly.is@gmail.com
wrote:
David Soria Parra dsp@php.net schrieb:
I think over the last years it proved to be good to have the current
RM support a new RM who then takes over after the final release
(e.g. Julien basically does 5.5 alone now, but we worked a lot
together
during alpha/beta/RC). Therefore my suggestion is that Julien is
going
to
help out with 5.6 and then we would need a new RM that can learn
from
julien
on how to do things to later be able to do 5.6 on his own.So I mabe think Ferenic (tyrael) would be a good RM.
I'm all for that as well :)
+1
Hi back !
I suggest we move forward on the topic.
We're gonna enter November soon, this is a dead line to branch 5.6.
I suggest we branch 5.6 from master, then run the 5.5 test suite against
the branch, and remove every commit that leads to a BC break.
The task shouldn't be too hard.When the branch is created, the wiki then would have to be updated to show
the ideas we'd like to support (https://wiki.php.net/todo/php56)Julien Pauli
Hi,
I was working on that last week, there are a couple of test related
changes which should/could be backported to 5.5 (and maybe even 5.4):http://git.php.net/?p=php-src.git;a=commitdiff;h=ecbe4af0de94c629fa5ba8ab169654e00c958bad
http://git.php.net/?p=php-src.git;a=commitdiff;h=361e984e462de5422bba5470d3961e67de327396
http://git.php.net/?p=php-src.git;a=commitdiff;h=95017c0522a9a1b9527d7cc1d866fbc3b89df7ac
I have sent an email to Sara/ptarjan, but got no response yet:
http://permalink.gmane.org/gmane.comp.php.cvs.general/62834The sole BC break I've found yet was the removal of $HTTP_RAW_POST_DATA
and co from Mike:http://git.php.net/?p=php-src.git;a=commitdiff;h=423c70fb4d79b7831b1db41ea217c8e1afd5cf8e
http://git.php.net/?p=php-src.git;a=commitdiff;h=449d4c0b1c6ea0f5dfe7b56c99d9fc4f2033d27c
http://git.php.net/?p=php-src.git;a=commitdiff;h=4a3936ef4abdeb72c7d323fe4b6a65e1ae0ef181
http://git.php.net/?p=php-src.git;a=commitdiff;h=8d087dc0d7c88e26539646875dc0f7bb5042187b
This would be a measurable improvement for many of our users with a
relatively easy way to restore/emulate the old behavior
($HTTP_RAW_POST_DATA = file_get_contents("php://input");) so maybe it
should be worth a discussion whether or not we should revert it from 5.6.
Mmmm, that's a break anyway, even if we provide solutions against it.
Can we afford it ?
Anyway, we should branch this week please.
I can give time this week to help on stuff, unfortunately I wont have time
this week-end but next one :-p
Julien.Pauli
On Wed, Oct 23, 2013 at 8:57 PM, Sherif Ramadan <theanomaly.is@gmail.com
wrote:
On Thu, Oct 17, 2013 at 1:24 AM, David Soria Parra dsp@php.net
wrote:David Soria Parra dsp@php.net schrieb:
I think over the last years it proved to be good to have the
current
RM support a new RM who then takes over after the final release
(e.g. Julien basically does 5.5 alone now, but we worked a lot
together
during alpha/beta/RC). Therefore my suggestion is that Julien is
going
to
help out with 5.6 and then we would need a new RM that can learn
from
julien
on how to do things to later be able to do 5.6 on his own.So I mabe think Ferenic (tyrael) would be a good RM.
I'm all for that as well :)
+1
Hi back !
I suggest we move forward on the topic.
We're gonna enter November soon, this is a dead line to branch 5.6.
I suggest we branch 5.6 from master, then run the 5.5 test suite against
the branch, and remove every commit that leads to a BC break.
The task shouldn't be too hard.When the branch is created, the wiki then would have to be updated to
show
the ideas we'd like to support (https://wiki.php.net/todo/php56)Julien Pauli
Hi,
I was working on that last week, there are a couple of test related
changes which should/could be backported to 5.5 (and maybe even 5.4):http://git.php.net/?p=php-src.git;a=commitdiff;h=ecbe4af0de94c629fa5ba8ab169654e00c958bad
http://git.php.net/?p=php-src.git;a=commitdiff;h=361e984e462de5422bba5470d3961e67de327396
http://git.php.net/?p=php-src.git;a=commitdiff;h=95017c0522a9a1b9527d7cc1d866fbc3b89df7ac
I have sent an email to Sara/ptarjan, but got no response yet:
http://permalink.gmane.org/gmane.comp.php.cvs.general/62834The sole BC break I've found yet was the removal of $HTTP_RAW_POST_DATA
and co from Mike:http://git.php.net/?p=php-src.git;a=commitdiff;h=423c70fb4d79b7831b1db41ea217c8e1afd5cf8e
http://git.php.net/?p=php-src.git;a=commitdiff;h=449d4c0b1c6ea0f5dfe7b56c99d9fc4f2033d27c
http://git.php.net/?p=php-src.git;a=commitdiff;h=4a3936ef4abdeb72c7d323fe4b6a65e1ae0ef181
http://git.php.net/?p=php-src.git;a=commitdiff;h=8d087dc0d7c88e26539646875dc0f7bb5042187b
This would be a measurable improvement for many of our users with a
relatively easy way to restore/emulate the old behavior
($HTTP_RAW_POST_DATA = file_get_contents("php://input");) so maybe it
should be worth a discussion whether or not we should revert it from 5.6.Mmmm, that's a break anyway, even if we provide solutions against it.
Can we afford it ?
I'm not fond of the idea myself, but I can see why others would disagree.
I will revert it from 5.6 though, and we can discuss it later.
Anyway, we should branch this week please.
I can give time this week to help on stuff, unfortunately I wont have time
this week-end but next one :-p
I will branch it today from master (without the raw post data BC break).
--
Ferenc Kovács
@Tyr43l - http://tyrael.hu
I have been running master and 5_5 PHPT tests against master snapshot
builds on all versions of Windows.
I have run the 5.5.6RC1 test-pack against snapshot builds of
master-ra0244a6 (x86, x64, ts and nts) and found no functional regressions
(no additional failures, timeouts or crashes) from php 5.5.6rc1, including
the x64 builds.
On Wed, Oct 23, 2013 at 8:57 PM, Sherif Ramadan <theanomaly.is@gmail.com
wrote:
David Soria Parra dsp@php.net schrieb:
I think over the last years it proved to be good to have the current
RM support a new RM who then takes over after the final release
(e.g. Julien basically does 5.5 alone now, but we worked a lot
together
during alpha/beta/RC). Therefore my suggestion is that Julien is
going
to
help out with 5.6 and then we would need a new RM that can learn from
julien
on how to do things to later be able to do 5.6 on his own.So I mabe think Ferenic (tyrael) would be a good RM.
I'm all for that as well :)
+1
Hi back !
I suggest we move forward on the topic.
We're gonna enter November soon, this is a dead line to branch 5.6.
I suggest we branch 5.6 from master, then run the 5.5 test suite against
the branch, and remove every commit that leads to a BC break.
The task shouldn't be too hard.
I get the same pass rate (no additional failures) for master ra0244a6 as I
get for 5.5.6rc1. We build the same extensions for 5.5 and master on
Windows, so the test coverage is the same. Forking master to 5.6 doesn't
seem to be a problem on Windows at least(no BC issues, etc...).
For more info, see
http://windows.php.net/downloads/snaps/ostc/pftt/PHP_Master/
-Matt