Hi!
As decided in https://wiki.php.net/rfc/php53eol, 5.3 EOL is 1 year after
the 5.5.0 release, which is on June 20th. Do we want to make one last
release before EOL with latest security patches (probably in sync with
5.4/5.5 releases planned for June 29)? If so, I can scan the logs and
backport the recent security-relevant patches. Last 5.3 was half a year
ago so we probably have some, even with remote exploit potential.
Thanks,
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
On Sat, Jun 14, 2014 at 1:38 AM, Stas Malyshev smalyshev@sugarcrm.com
wrote:
Hi!
As decided in https://wiki.php.net/rfc/php53eol, 5.3 EOL is 1 year after
the 5.5.0 release, which is on June 20th. Do we want to make one last
release before EOL with latest security patches (probably in sync with
5.4/5.5 releases planned for June 29)? If so, I can scan the logs and
backport the recent security-relevant patches. Last 5.3 was half a year
ago so we probably have some, even with remote exploit potential.Thanks,
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227--
+1 for having a final release, stating in the announcement than there will
be no more releases and urging everybody not using 5.3 from a distro who
still provides support to upgrade it ASAP.
--
Ferenc Kovács
@Tyr43l - http://tyrael.hu
On Sat, Jun 14, 2014 at 1:38 AM, Stas Malyshev smalyshev@sugarcrm.com
wrote:Hi!
As decided in https://wiki.php.net/rfc/php53eol, 5.3 EOL is 1 year after
the 5.5.0 release, which is on June 20th. Do we want to make one last
release before EOL with latest security patches (probably in sync with
5.4/5.5 releases planned for June 29)? If so, I can scan the logs and
backport the recent security-relevant patches. Last 5.3 was half a year
ago so we probably have some, even with remote exploit potential.
Very nice idea Stas.
One last release before definitive death.
Requiescat in pace
Julien P
Hi,
As decided in https://wiki.php.net/rfc/php53eol, 5.3 EOL is 1 year after
the 5.5.0 release, which is on June 20th. Do we want to make one last
release before EOL with latest security patches (probably in sync with
5.4/5.5 releases planned for June 29)? If so, I can scan the logs and
backport the recent security-relevant patches. Last 5.3 was half a year
ago so we probably have some, even with remote exploit potential.
The last time this was discussed on security@ I intended for "having one
release in July to send 5.3 to eternal sleep" I still plan to do that.
I won't directly sync with 5.4/5.5, though (unless there is a critical
issue requiring this) to have different news. I expect this final EOL to
receive more media echo which shouldn't hide other releases.
If there are specific changes you want to see in there please send a
note to me (cc security@), I'll check myself, too.
johannes
On Sat, Jun 14, 2014 at 2:45 PM, Johannes Schlüter johannes@schlueters.de
wrote:
Hi,
As decided in https://wiki.php.net/rfc/php53eol, 5.3 EOL is 1 year after
the 5.5.0 release, which is on June 20th. Do we want to make one last
release before EOL with latest security patches (probably in sync with
5.4/5.5 releases planned for June 29)? If so, I can scan the logs and
backport the recent security-relevant patches. Last 5.3 was half a year
ago so we probably have some, even with remote exploit potential.The last time this was discussed on security@ I intended for "having one
release in July to send 5.3 to eternal sleep" I still plan to do that.I won't directly sync with 5.4/5.5, though (unless there is a critical
issue requiring this) to have different news. I expect this final EOL to
receive more media echo which shouldn't hide other releases.If there are specific changes you want to see in there please send a
note to me (cc security@), I'll check myself, too.johannes
--
Hi Johannes,
I would like to cherry-pick
http://git.php.net/?p=php-src.git;a=commit;h=4d804aa52d8c74ddcbdb07694b75b38c5eba8004
into PHP-5.3 so that
REPORT_EXIT_STATUS=1 make test
can be used on every php version provided by travis.
currently one has to either manually execute run-tests.php or grepping the
make test output for failures.
Would that be ok with you?
--
Ferenc Kovács
@Tyr43l - http://tyrael.hu
bump.
On Sat, Jun 14, 2014 at 2:45 PM, Johannes Schlüter <johannes@schlueters.de
wrote:
Hi,
As decided in https://wiki.php.net/rfc/php53eol, 5.3 EOL is 1 year
after
the 5.5.0 release, which is on June 20th. Do we want to make one last
release before EOL with latest security patches (probably in sync with
5.4/5.5 releases planned for June 29)? If so, I can scan the logs and
backport the recent security-relevant patches. Last 5.3 was half a year
ago so we probably have some, even with remote exploit potential.The last time this was discussed on security@ I intended for "having one
release in July to send 5.3 to eternal sleep" I still plan to do that.I won't directly sync with 5.4/5.5, though (unless there is a critical
issue requiring this) to have different news. I expect this final EOL to
receive more media echo which shouldn't hide other releases.If there are specific changes you want to see in there please send a
note to me (cc security@), I'll check myself, too.johannes
--
Hi Johannes,
I would like to cherry-pick
http://git.php.net/?p=php-src.git;a=commit;h=4d804aa52d8c74ddcbdb07694b75b38c5eba8004
into PHP-5.3 so that
REPORT_EXIT_STATUS=1 make test
can be used on every php version provided by travis.
currently one has to either manually execute run-tests.php or grepping the
make test output for failures.
Would that be ok with you?--
Ferenc Kovács
@Tyr43l - http://tyrael.hu
--
Ferenc Kovács
@Tyr43l - http://tyrael.hu
Hi!
According to PHP 5.3 EOL RFC, we've now a month past official EOL date,
but we've planned to make one final release incorporating most important
fixes from upper branches since the last 5.3 release. To help with that,
I've created a pull here:
https://github.com/php/php-src/pull/730
That lists such fixes. Please review and see if you see anything that
should be there and is not, or anything that should not be there but
still is.
Thanks,
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
Hi!
According to PHP 5.3 EOL RFC, we've now a month past official EOL date,
but we've planned to make one final release incorporating most important
fixes from upper branches since the last 5.3 release. To help with that,
I've created a pull here:
Did not get any response for that - I guess everybody's too busy
discussing the number of the next PHP version :) But I think we still
need to release the final 5.3. So I plan to proceed this way:
- Release the RC next week
- Release the final 5.3 version on August 14th.
Any objections to this plan?
If anybody has any way to reach Johannes and see if he wants to do it
himself later or is ok with the plan above, that'd be great.
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
Hi,
Hi!
According to PHP 5.3 EOL RFC, we've now a month past official EOL date,
but we've planned to make one final release incorporating most important
fixes from upper branches since the last 5.3 release. To help with that,
I've created a pull here:
Thanks for the work! The list looks good. Any opinions on #67541? WHich
was requested there? going strict by the rules it won't qualify.
johannes
Hi,
Hi!
According to PHP 5.3 EOL RFC, we've now a month past official EOL date,
but we've planned to make one final release incorporating most
important
fixes from upper branches since the last 5.3 release. To help with
that,
I've created a pull here:Thanks for the work! The list looks good. Any opinions on #67541? WHich
was requested there? going strict by the rules it won't qualify.johannes
not sure, have you seen https://bugs.php.net/bug.php?id=67606 ?
Hi!
not sure, have you seen https://bugs.php.net/bug.php?id=67606 ?
This is worrying. Looks like the patch is not as safe as we've hoped,
and causes BC issues for mod_fastcgi, so maybe we should not get it into
5.3. Once it stabilizes, we can backport it into 5.4, but for 5.3 better
safe than sorry.
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
Hi!
not sure, have you seen https://bugs.php.net/bug.php?id=67606 ?
This is worrying. Looks like the patch is not as safe as we've hoped,
and causes BC issues for mod_fastcgi, so maybe we should not get it into
5.3. Once it stabilizes, we can backport it into 5.4, but for 5.3 better
safe than sorry.
I’ll be working on a fix this week. If you can wait a few days, that’d be grand; if not, then no biggie.
David
Hi!
not sure, have you seen https://bugs.php.net/bug.php?id=67606 ?
This is worrying. Looks like the patch is not as safe as we've hoped,
and causes BC issues for mod_fastcgi, so maybe we should not get it into
5.3. Once it stabilizes, we can backport it into 5.4, but for 5.3 better
safe than sorry.I’ll be working on a fix this week. If you can wait a few days, that’d be grand; if not, then no biggie.
as we are on the truly last release for 5.3 we have to be safe. We can
provide the patch for people who want to experiment, though.
So I'd say no for 5.3.
johannes
Thanks for the work! The list looks good. Any opinions on #67541? WHich was requested there? going strict by the rules it won't qualify. johannesnot sure, have you seen https://bugs.php.net/bug.php?id=67606 ?
that makes it a "no" :-)
johannes
Hi!
Thanks for the work! The list looks good. Any opinions on #67541? WHich
was requested there? going strict by the rules it won't qualify.
In principle, I don't have anything against it but I'm not familiar with
the code there enough to understand the full set of consequences. I'd
like to hear from FPM maintainers/original authors, if they're OK with
it then we can have it in 5.3.
--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
Hi,
I have a request to include our latest sapi/litespeed V6.6 to the EOL
PHP 5.3 release. I thought it was EOL already.
We had some difficult to commit our LiteSpeed SAPI code into PHP source
repository before, so it is lagging behind our office release.
The sapi/litespeed code in 5.3.28 is the V5.5 release, which is very
old. We have a script to patch LiteSpeed SAPI to latest version when
user build PHP binary for production use. However, we start to push for
rpm packages, some vendors only take the official PHP release. It could
be a big problem for PHP 5.3 if only the official code is used. PHP
5.4/5.5/5.6 branch has been updated to the latest, and will be kept
up2date from now on.
Fortunately, there are one more release for 5.3, I sent in a pull
request for the PHP-5.3 branch on Github which updates sapi/litespeed
code to the latest v6.6, it is the version has used in production for
long time.
https://github.com/php/php-src/pull/739
Hopefully, it is not too late. :-)
Thanks,
George Wang
Hi!
According to PHP 5.3 EOL RFC, we've now a month past official EOL date,
but we've planned to make one final release incorporating most important
fixes from upper branches since the last 5.3 release. To help with that,
I've created a pull here:https://github.com/php/php-src/pull/730
Did not get any response for that - I guess everybody's too busy
discussing the number of the next PHP version :) But I think we still
need to release the final 5.3. So I plan to proceed this way:
- Release the RC next week
- Release the final 5.3 version on August 14th.
Any objections to this plan?
If anybody has any way to reach Johannes and see if he wants to do it
himself later or is ok with the plan above, that'd be great.
Hi,
I have a request to include our latest sapi/litespeed V6.6 to the EOL
PHP 5.3 release. I thought it was EOL already.
PHP 5.3 is in extended support and only receives security related fixes.
In general people should use newer versions which have more bug fixes
and are faster.
I don't think these updates qualify.
We had some difficult to commit our LiteSpeed SAPI code into PHP
source repository before, so it is lagging behind our office release.
What kind of issues?
johannes
Hi,
I have a request to include our latest sapi/litespeed V6.6 to the EOL
PHP 5.3 release. I thought it was EOL already.
PHP 5.3 is in extended support and only receives security related fixes.
In general people should use newer versions which have more bug fixes
and are faster.
I don't think these updates qualify.We had some difficult to commit our LiteSpeed SAPI code into PHP
source repository before, so it is lagging behind our office release.
What kind of issues?
A while back, I can only push change to master branch, but cannot push
to other branches.
So, master was updated to V6.4 last year, but other branches still stay
at V5.5, which was released 4 years ago.
I can push changes to other branches without problem now, all up2date
now except the 5.3 branch.
Best regards,
George
On Fri, Jul 25, 2014 at 12:23 AM, George Wang gwang@litespeedtech.com
wrote:
Hi,
I have a request to include our latest sapi/litespeed V6.6 to the EOL
PHP 5.3 release. I thought it was EOL already.PHP 5.3 is in extended support and only receives security related fixes.
In general people should use newer versions which have more bug fixes
and are faster.
I don't think these updates qualify.We had some difficult to commit our LiteSpeed SAPI code into PHP
source repository before, so it is lagging behind our office release.
What kind of issues?
A while back, I can only push change to master branch, but cannot push to
other branches.
So, master was updated to V6.4 last year, but other branches still stay at
V5.5, which was released 4 years ago.I can push changes to other branches without problem now, all up2date now
except the 5.3 branch.Best regards,
George--
as I mentioned previously when you reported the issue, based on the push
reject message, you were trying to push to a subdirectory, where you didn't
have access (probably had something not merged upwards in Zend/ or similar).
--
Ferenc Kovács
@Tyr43l - http://tyrael.hu
as I mentioned previously when you reported the issue, based on the
push reject message, you were trying to push to a subdirectory, where
you didn't have access (probably had something not merged upwards in
Zend/ or similar).
All my changes were under sapi/litespeed directory, did the same thing
to the master branch.
Anyway, it is the past, let's deal with the present issue now.
I just found that my commits to PHP-5.4.31 and PHP-5.5.15 branch have
been voided, the result is that in final 5.4.31 and 5.5.15 release
package, sapi/litespeed code is still the ancient V5.5 release, it is
ridiculous!
I got an email from Stas regarding my commits, I replied, but the end
result is still like this.
What is the procedure to make sure our latest sapi/litespeed release
will be in the next release?
Best regards,
George Wang
Hi!
I just found that my commits to PHP-5.4.31 and PHP-5.5.15 branch have
been voided, the result is that in final 5.4.31 and 5.5.15 release
package, sapi/litespeed code is still the ancient V5.5 release, it is
ridiculous!
No, it is not ridiculous, it is the release process. The three-number
branches are release branches, and no commits but by the RMs should be
done there. Moreover, even by the RMs the only commits that go there
once the release is branched is either technical release commits
(versions, NEWS, etc.) or urgent high-profile security fixes which could
not be done in development branches, or other exceptional commits (like
somebody discovering at the last moment Windows build is broken).
In general, once the release branch is created, it is frozen except for
urgent fixes, RC fixes/reverts and other exceptional cases. The decision
of which commits to include is by the RM of the branch.
The regular commits go into development branches - PHP-5.4, PHP-5.5,
etc. I've sent you an email to verify if it is not an urgent commit, but
both from review and from your answers it was clear that it was not, and
there's no compelling reason to override regular release flow for it.
Thus, these commits were not included into releases that were already
well under way.
What is the procedure to make sure our latest sapi/litespeed release
will be in the next release?
Creating a pull request and after review etc. committing it to the
development branches - PHP-5.4, PHP-5.5, etc. There's more info here:
https://wiki.php.net/vcs/gitworkflow
In the future, I would recommend to ask on the list if the procedure is
not clear. I understand there was a lot of change in how PHP release
process works in the last couple of years, and not everybody may be up
to date with it. Please ask and we will answer. We have docs, we have
guides and we have this list where there are a number of people who can
explain how to do things right. We've outgrown the situation of cowboy
release management, we have a process now, which has been working pretty
well so far. I am sorry that it caused your frustration, but be assured
your changes are not lost and will be released in the next version in
accordance to the regular release process.
I would also encourage you to update NEWS files for the release branches
from 5.4 up to reflect your changes. The changes are always made to the
topmost release in the NEWS file.
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
All right, looks like it is my fault not making the reply sounds
critical enough. It pretty much make all third party php-litespeed rpms
useless, only causes trouble and confusion for LiteSpeed users.
Maybe the release branches should be only open to the RMs, save everyone
time and efforts and force to follow the procedure.
So, now moving forward, the code should be in PHP-5.4/5.5/5.6 branches
already, I will update NEWS files in 5.4/5.5/5.6 branches, anything
else? I want to make sure the LiteSpeed SAPI code is up2date in next
release.
Best regards,
George Wang
Hi!
I just found that my commits to PHP-5.4.31 and PHP-5.5.15 branch have
been voided, the result is that in final 5.4.31 and 5.5.15 release
package, sapi/litespeed code is still the ancient V5.5 release, it is
ridiculous!
No, it is not ridiculous, it is the release process. The three-number
branches are release branches, and no commits but by the RMs should be
done there. Moreover, even by the RMs the only commits that go there
once the release is branched is either technical release commits
(versions, NEWS, etc.) or urgent high-profile security fixes which could
not be done in development branches, or other exceptional commits (like
somebody discovering at the last moment Windows build is broken).In general, once the release branch is created, it is frozen except for
urgent fixes, RC fixes/reverts and other exceptional cases. The decision
of which commits to include is by the RM of the branch.The regular commits go into development branches - PHP-5.4, PHP-5.5,
etc. I've sent you an email to verify if it is not an urgent commit, but
both from review and from your answers it was clear that it was not, and
there's no compelling reason to override regular release flow for it.
Thus, these commits were not included into releases that were already
well under way.What is the procedure to make sure our latest sapi/litespeed release
will be in the next release?
Creating a pull request and after review etc. committing it to the
development branches - PHP-5.4, PHP-5.5, etc. There's more info here:
https://wiki.php.net/vcs/gitworkflowIn the future, I would recommend to ask on the list if the procedure is
not clear. I understand there was a lot of change in how PHP release
process works in the last couple of years, and not everybody may be up
to date with it. Please ask and we will answer. We have docs, we have
guides and we have this list where there are a number of people who can
explain how to do things right. We've outgrown the situation of cowboy
release management, we have a process now, which has been working pretty
well so far. I am sorry that it caused your frustration, but be assured
your changes are not lost and will be released in the next version in
accordance to the regular release process.I would also encourage you to update NEWS files for the release branches
from 5.4 up to reflect your changes. The changes are always made to the
topmost release in the NEWS file.
Hi George,
is there any reason why seemingly you never read my original mail about
those branches beeing off-limit and those commit gonna be reverted?
http://news.php.net/php.cvs/79411
ps: we prefer bottom-posting on the php.net lists, and that hasn't changed
in the last couple of years.
On Sat, Jul 26, 2014 at 12:24 AM, George Wang gwang@litespeedtech.com
wrote:
All right, looks like it is my fault not making the reply sounds critical
enough. It pretty much make all third party php-litespeed rpms useless,
only causes trouble and confusion for LiteSpeed users.Maybe the release branches should be only open to the RMs, save everyone
time and efforts and force to follow the procedure.So, now moving forward, the code should be in PHP-5.4/5.5/5.6 branches
already, I will update NEWS files in 5.4/5.5/5.6 branches, anything else? I
want to make sure the LiteSpeed SAPI code is up2date in next release.Best regards,
George WangHi!
I just found that my commits to PHP-5.4.31 and PHP-5.5.15 branch have
been voided, the result is that in final 5.4.31 and 5.5.15 release
package, sapi/litespeed code is still the ancient V5.5 release, it is
ridiculous!No, it is not ridiculous, it is the release process. The three-number
branches are release branches, and no commits but by the RMs should be
done there. Moreover, even by the RMs the only commits that go there
once the release is branched is either technical release commits
(versions, NEWS, etc.) or urgent high-profile security fixes which could
not be done in development branches, or other exceptional commits (like
somebody discovering at the last moment Windows build is broken).In general, once the release branch is created, it is frozen except for
urgent fixes, RC fixes/reverts and other exceptional cases. The decision
of which commits to include is by the RM of the branch.The regular commits go into development branches - PHP-5.4, PHP-5.5,
etc. I've sent you an email to verify if it is not an urgent commit, but
both from review and from your answers it was clear that it was not, and
there's no compelling reason to override regular release flow for it.
Thus, these commits were not included into releases that were already
well under way.What is the procedure to make sure our latest sapi/litespeed release
will be in the next release?
Creating a pull request and after review etc. committing it to the
development branches - PHP-5.4, PHP-5.5, etc. There's more info here:
https://wiki.php.net/vcs/gitworkflowIn the future, I would recommend to ask on the list if the procedure is
not clear. I understand there was a lot of change in how PHP release
process works in the last couple of years, and not everybody may be up
to date with it. Please ask and we will answer. We have docs, we have
guides and we have this list where there are a number of people who can
explain how to do things right. We've outgrown the situation of cowboy
release management, we have a process now, which has been working pretty
well so far. I am sorry that it caused your frustration, but be assured
your changes are not lost and will be released in the next version in
accordance to the regular release process.I would also encourage you to update NEWS files for the release branches
from 5.4 up to reflect your changes. The changes are always made to the
topmost release in the NEWS file.
--
Ferenc Kovács
@Tyr43l - http://tyrael.hu
Hi Ferenc,
is there any reason why seemingly you never read my original mail
about those branches beeing off-limit and those commit gonna be reverted?
http://news.php.net/php.cvs/79411
That's my fault due to how my email filters was configured.
Just a suggestion to make the collaboration better. After all it is
mainly due to my unfamiliarity with the releasing process, it costs not
only me but others' precious time to deal with it. It could be avoided
if my cherry-picks are declined with message like "please contact the
release master."
ps: we prefer bottom-posting on the php.net http://php.net lists,
and that hasn't changed in the last couple of years.
Sorry, will do that from now on.
Best regards,
George Wang
Hi!
All right, looks like it is my fault not making the reply sounds
critical enough. It pretty much make all third party php-litespeed rpms
useless, only causes trouble and confusion for LiteSpeed users.
I'm not sure what changed with the last php release - the old code was
there for a long time, so why 5.4.31 was critical while 5.4.30 was not?
So, now moving forward, the code should be in PHP-5.4/5.5/5.6 branches
already, I will update NEWS files in 5.4/5.5/5.6 branches, anything
else? I want to make sure the LiteSpeed SAPI code is up2date in next
release.
Nothing else, just test the RC when they will be announced (in 2 weeks,
the releases work in 2-week cycles, RC then GA) and see it works well
for you. If it does, everything is fine and the release will be out in
another 2 weeks. If not, alert the RMs ASAP and we'll try to fix it.
--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
Hi,
Hi!
All right, looks like it is my fault not making the reply sounds
critical enough. It pretty much make all third party php-litespeed rpms
useless, only causes trouble and confusion for LiteSpeed users.
I'm not sure what changed with the last php release - the old code was
there for a long time, so why 5.4.31 was critical while 5.4.30 was not?
That's because REMI repository will release php-litespeed RPM for
5.4.31, and it is purely based on the official PHP release, without
applying our V6.6 patch.Nothing else, just test the RC when they will be announced (in 2 weeks,
the releases work in 2-week cycles, RC then GA) and see it works well
for you. If it does, everything is fine and the release will be out in
another 2 weeks. If not, alert the RMs ASAP and we'll try to fix it.
I have updated the NEWS with pull requests through github.
Thanks,
George Wang