# PHP 5.6 Process - Thread: https://externals.io/message/69555 - Original archive: https://news-web.php.net/php.internals/69555 - Started by David Soria Parra on 2013-10-14T21:43:13+00:00 - Messages: 23 - Reply by email to internals@lists.php.net - More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt --- ## #69555 — David Soria Parra — 2013-10-14T21:43:13+00:00 URL: https://externals.io/message/69555#69555 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 --- ## #69558 — Ferenc Kovacs — 2013-10-15T12:19:14+00:00 URL: https://externals.io/message/69555#69558 · In reply to: #69555 > 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 --- ## #69561 — Julien Pauli — 2013-10-15T13:11:12+00:00 URL: https://externals.io/message/69555#69561 · In reply to: #69555 > 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 --- ## #69562 — Pierre Joye — 2013-10-15T13:31:58+00:00 URL: https://externals.io/message/69555#69562 · In reply to: #69555 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 --- ## #69563 — David Soria Parra — 2013-10-15T14:45:58+00:00 URL: https://externals.io/message/69555#69563 · In reply to: #69558 -----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 --- ## #69574 — ondrej@sury.org — 2013-10-16T06:40:30+00:00 URL: https://externals.io/message/69555#69574 · In reply to: #69555 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ý 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 --- ## #69575 — Pierre Joye — 2013-10-16T06:51:02+00:00 URL: https://externals.io/message/69555#69575 · In reply to: #69574 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 --- ## #69577 — Rasmus Lerdorf — 2013-10-16T09:03:43+00:00 URL: https://externals.io/message/69555#69577 · In reply to: #69574 > 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 --- ## #69595 — David Soria Parra — 2013-10-17T05:24:04+00:00 URL: https://externals.io/message/69555#69595 · In reply to: #69555 David Soria Parra 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 --- ## #69622 — Julien Pauli — 2013-10-17T14:24:17+00:00 URL: https://externals.io/message/69555#69622 · In reply to: #69595 > David Soria Parra schrieb: > > […] > julien > > […] > > 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 --- ## #69623 — Felipe Pena — 2013-10-17T14:29:35+00:00 URL: https://externals.io/message/69555#69623 · In reply to: #69622 > > > > […] > performed complementary tasks :-) > I'm all +1 for Ferenic (tyrael) > > Julien +1 for Ferenc Kovacs. (is it a voting thread? :D) -- Regards, Felipe Pena --- ## #69629 — Michael Wallner — 2013-10-17T14:56:27+00:00 URL: https://externals.io/message/69555#69629 · In reply to: #69623 > > +1 for Ferenc Kovacs. (is it a voting thread? :D) +1 (let's make it a good ol' one :)) -- Regards, Mike --- ## #69632 — Pierre Joye — 2013-10-17T15:29:14+00:00 URL: https://externals.io/message/69555#69632 · In reply to: #69629 > > > > […] > > +1 (let's make it a good ol' one :)) +1 for both -- Pierre @pierrejoye | http://www.libgd.org --- ## #69662 — Ferenc Kovacs — 2013-10-18T05:19:17+00:00 URL: https://externals.io/message/69555#69662 · In reply to: #69632 > > > […] > > +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 --- ## #69808 — Christopher Jones — 2013-10-23T17:47:20+00:00 URL: https://externals.io/message/69555#69808 · In reply to: #69662 > > > > […] > 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 --- ## #69814 — Sherif Ramadan — 2013-10-23T18:57:46+00:00 URL: https://externals.io/message/69555#69814 · In reply to: #69595 > David Soria Parra schrieb: > > […] > julien > > […] > > So I mabe think Ferenic (tyrael) would be a good RM. I'm all for that as well :) +1 --- ## #69924 — Julien Pauli — 2013-10-29T08:22:20+00:00 URL: https://externals.io/message/69555#69924 · In reply to: #69814 On Wed, Oct 23, 2013 at 8:57 PM, Sherif Ramadan wrote: > > > > […] > to > > […] > > > 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 --- ## #69925 — Ferenc Kovacs — 2013-10-29T08:40:09+00:00 URL: https://externals.io/message/69555#69925 · In reply to: #69924 > On Wed, Oct 23, 2013 at 8:57 PM, Sherif Ramadan > […] > > > […] > together > > […] > going > > […] > > 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 --- ## #70016 — Julien Pauli — 2013-11-05T18:03:20+00:00 URL: https://externals.io/message/69555#70016 · In reply to: #69925 > > > > > > > […] > > > 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. > 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 --- ## #70028 — Ferenc Kovacs — 2013-11-06T09:19:07+00:00 URL: https://externals.io/message/69555#70028 · In reply to: #70016 > > > > […] > > 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 --- ## #70033 — Derick Rethans — 2013-11-06T13:44:36+00:00 URL: https://externals.io/message/69555#70033 · In reply to: #69629 > > > > […] > > +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 --- ## #70034 — Ferenc Kovacs — 2013-11-06T13:47:26+00:00 URL: https://externals.io/message/69555#70034 · In reply to: #70033 > > > > […] > > 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 --- ## #70043 — Matt F — 2013-11-06T22:28:34+00:00 URL: https://externals.io/message/69555#70043 · In reply to: #69924 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 > […] > > > […] > together > > […] > going > > […] > > 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