Hi,
based on the discussion of the last few days and the reached consent, the final date of the 7.0.0 RTM is shifted. RC8 is planned to appear on November 26th instead of GA. 7.0.0 RTM will follow shortly on December 3rd.
The final release is going to be identical to RC8 with the exception of the bugs considered security relevant. Those still might be applied, if any.
Looking straight forward to 7.0.0 RTM!
Thanks everyone
Anatol
Hi,
-----Original Message-----
From: Anatol Belski [mailto:weltling@outlook.de]
Sent: Tuesday, November 24, 2015 5:39 PM
To: internals@lists.php.net
Subject: [PHP-DEV] PHP 7.0.0 final RTM delayHi,
based on the discussion of the last few days and the reached consent, the
final
date of the 7.0.0 RTM is shifted. RC8 is planned to appear on November
26th
instead of GA. 7.0.0 RTM will follow shortly on December 3rd.The final release is going to be identical to RC8 with the exception of
the bugs
considered security relevant. Those still might be applied, if any.Looking straight forward to 7.0.0 RTM!
A short note to this is that due to the OpenSSL release on December 3rd that
makes full sense to be included with the Windows builds, the PHP 7.0.0
announcement will most likely appear later afternoon.
Regards
Anatol
Am 02.12.2015 um 08:34 schrieb Anatol Belski:
A short note to this is that due to the OpenSSL release on December 3rd that
makes full sense to be included with the Windows builds, the PHP 7.0.0
announcement will most likely appear later afternoon.
Do the Windows builds have to be available immediately when the
sources of PHP 7.0.0 are released?
-----Original Message-----
From: Sebastian Bergmann [mailto:sebastian@php.net]
Sent: Wednesday, December 2, 2015 9:01 AM
To: internals@lists.php.net
Subject: Re: [PHP-DEV] PHP 7.0.0 final RTM delayAm 02.12.2015 um 08:34 schrieb Anatol Belski:
A short note to this is that due to the OpenSSL release on December
3rd that makes full sense to be included with the Windows builds, the
PHP 7.0.0 announcement will most likely appear later afternoon.Do the Windows builds have to be available immediately when the sources
of
PHP 7.0.0 are released?
Yes.
Regards
Anatol
How’s it going? Are we golden?
When do you plan on posting tomorrow?
-----Original Message-----
From: Sebastian Bergmann [mailto:sebastian@php.net]
Sent: Wednesday, December 2, 2015 9:01 AM
To: internals@lists.php.net
Subject: Re: [PHP-DEV] PHP 7.0.0 final RTM delayAm 02.12.2015 um 08:34 schrieb Anatol Belski:
A short note to this is that due to the OpenSSL release on December
3rd that makes full sense to be included with the Windows builds, the
PHP 7.0.0 announcement will most likely appear later afternoon.Do the Windows builds have to be available immediately when the sources
of
PHP 7.0.0 are released?
Yes.Regards
Anatol
Hi Andi,
-----Original Message-----
From: Andi Gutmans [mailto:andi@zend.com]
Sent: Wednesday, December 2, 2015 10:34 PM
To: Anatol Belski anatol.php@belski.net
Cc: Sebastian Bergmann sebastian@php.net; internals@lists.php.net
Subject: Re: [PHP-DEV] PHP 7.0.0 final RTM delayHow’s it going? Are we golden?
When do you plan on posting tomorrow?
OpenSSL is releasing on 3rd between 1pm and 5pm UTC and contains some security fixes. As soon it is out, it'll need some time to build the bins and to test - that the normal practice when we collide with some library like OpenSSL. So the announcement will most likely shift into the later afternoon, still same day by UTC and most other time zones. That's the plan, nothing else can really stop it.
Regards
Anatol
"Anatol Belski" in php.internals (Wed, 2 Dec 2015 23:04:52 +0100):
OpenSSL is releasing on 3rd between 1pm and 5pm UTC and contains some
security fixes. As soon it is out, it'll need some time to build the bins
and to test - that the normal practice when we collide with some library
like OpenSSL. So the announcement will most likely shift into the later
afternoon, still same day by UTC and most other time zones. That's the
plan, nothing else can really stop it.
Will you include cUrl 7.46.0 as well? It was released a few hours ago and
has no issues in upgrading AFAIK.
Libxml2 2.9.3 was also released recently. I did not encouter any problems
with the update from 2.9.2
Jan
Hi Jan,
-----Original Message-----
From: Jan Ehrhardt [mailto:phpdev@ehrhardt.nl]
Sent: Thursday, December 3, 2015 1:53 AM
To: internals@lists.php.net
Subject: Re: [PHP-DEV] PHP 7.0.0 final RTM delay"Anatol Belski" in php.internals (Wed, 2 Dec 2015 23:04:52 +0100):
OpenSSL is releasing on 3rd between 1pm and 5pm UTC and contains some
security fixes. As soon it is out, it'll need some time to build the
bins and to test - that the normal practice when we collide with some
library like OpenSSL. So the announcement will most likely shift into
the later afternoon, still same day by UTC and most other time zones.
That's the plan, nothing else can really stop it.Will you include cUrl 7.46.0 as well? It was released a few hours ago and
has no
issues in upgrading AFAIK.Libxml2 2.9.3 was also released recently. I did not encouter any problems
with
the update from 2.9.2
The regular library upgrades are not planned for 7.0.0, but will take for
the later versions. OpenSSL however is security conditioned.
Regards
Anatol
Am 02.12.2015 um 09:42 schrieb Anatol Belski:
Do the Windows builds have to be available immediately when the
sources of PHP 7.0.0 are released?
Yes.
http://git.php.net/?p=php-src.git;a=blob;f=README.RELEASE_PROCESS
currently reads
"Ensure that Windows builds will work before packaging"
in the "General notes and tips" section and then later in the
"Rolling a stable release" section
"Once the release has been tagged, contact the PHP Windows
development team (internals-win@lists.php.net) so that Windows
binaries can be created."
I do not think that this means that the release of the source
tarball must wait for the availability of the Windows binaries.
In fact, step 2g of "Getting the stable release announced" explains
what to do when the Windows binaries are not available at the time
of release.
Please do not get me wrong: I appreciate what Microsoft in general
and you, Anatol, as well as Pierre in particular have done for PHP.
But no vendor -- neither Microsoft nor Red Hat nor whoever else
rolls binary distributions of PHP -- should have the power to delay
a release in my opinion.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Le 03/12/2015 06:51, Sebastian Bergmann a écrit :
Am 02.12.2015 um 09:42 schrieb Anatol Belski:
Do the Windows builds have to be available immediately when
the sources of PHP 7.0.0 are released?
Yes.
I do not think that this means that the release of the source
tarball must wait for the availability of the Windows binaries.
I agree, this can't be a blocker.
But, in the past, downstream build done "before" announcement have
allowed us to detect and don't distribute broken versions.
e.g.
-
- a recent 7.0.0RC was retagged because of huge regression in the
session management
- a recent 7.0.0RC was retagged because of huge regression in the
-
- a recent 5.6 released was repackaged because of missing files in the
"not-yet-official" archive
- a recent 5.6 released was repackaged because of missing files in the
So, waiting a "few" hours is not a really big issue.
Of course, as there is a huge expectation for this version, and
internet have already start talking about it, we should really
announce it today.
My 0.02€
Remi.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iEYEARECAAYFAlZf59AACgkQYUppBSnxahh05QCdEr0C86UK0/Sjx7whGEuIsYv2
NYQAoLZVhy/Yu4xCiOToy5ERqJPslmL3
=aXN3
-----END PGP SIGNATURE
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1Le 03/12/2015 06:51, Sebastian Bergmann a écrit :
Am 02.12.2015 um 09:42 schrieb Anatol Belski:
Do the Windows builds have to be available immediately when
the sources of PHP 7.0.0 are released?
Yes.I do not think that this means that the release of the source
tarball must wait for the availability of the Windows binaries.I agree, this can't be a blocker.
But, in the past, downstream build done "before" announcement have
allowed us to detect and don't distribute broken versions.
On spot. Exactly that.
And testing that latest openssl releases (which includes security fixes)
work well with a php release looks like a blocker to me, even more if it
only means a couple of hours.
We had cases where the delay was days not hours, but we did not wait.
e.g.
- a recent 7.0.0RC was retagged because of huge regression in the
session management
- a recent 5.6 released was repackaged because of missing files in the
"not-yet-official" archiveSo, waiting a "few" hours is not a really big issue.
Of course, as there is a huge expectation for this version, and
internet have already start talking about it, we should really
announce it today.
Please do not get me wrong: I appreciate what Microsoft in general
and you, Anatol, as well as Pierre in particular have done for PHP.
But no vendor -- neither Microsoft nor Red Hat nor whoever else
rolls binary distributions of PHP -- should have the power to delay
a release in my opinion.
Ditto. Never remember any such thing in PHP history. Binary builds should not be a blocker to releases. Not Windows/MSFT, Zend, Red Hat or anyone...
Andi
Hi Andi,
-----Original Message-----
From: Andi Gutmans [mailto:andi@zend.com]
Sent: Thursday, December 3, 2015 8:43 AM
To: Sebastian Bergmann sebastian@php.net
Cc: internals@lists.php.net
Subject: Re: [PHP-DEV] PHP 7.0.0 final RTM delayOn Dec 2, 2015, at 9:51 PM, Sebastian Bergmann sebastian@php.net
wrote:Please do not get me wrong: I appreciate what Microsoft in general and
you, Anatol, as well as Pierre in particular have done for PHP.
But no vendor -- neither Microsoft nor Red Hat nor whoever else rolls
binary distributions of PHP -- should have the power to delay a
release in my opinion.Ditto. Never remember any such thing in PHP history. Binary builds should
not be
a blocker to releases. Not Windows/MSFT, Zend, Red Hat or anyone...
No one was talking about a "blocker", everything looks good for today. A
blocker colud be a critical issue, which by chance are often discovered
short before release by the suspects you mentioned. No such issues are known
ATM.
Regards
Anatol
Am 03.12.2015 um 09:26 schrieb Anatol Belski:
No one was talking about a "blocker", everything looks good for today. A
blocker colud be a critical issue, which by chance are often discovered
short before release by the suspects you mentioned. No such issues are known
ATM.
The decision to wait for a release of a third-party library before the
Windows binaries are built is a blocker as it puts the release of PHP
on hold.
Hi Sebastian,
-----Original Message-----
From: Sebastian Bergmann [mailto:sebastian@php.net]
Sent: Thursday, December 3, 2015 9:39 AM
To: internals@lists.php.net
Subject: Re: [PHP-DEV] PHP 7.0.0 final RTM delayAm 03.12.2015 um 09:26 schrieb Anatol Belski:
No one was talking about a "blocker", everything looks good for today.
A blocker colud be a critical issue, which by chance are often
discovered short before release by the suspects you mentioned. No such
issues are known ATM.The decision to wait for a release of a third-party library before the
Windows
binaries are built is a blocker as it puts the release of PHP on hold.
IMHO offering a secure release which also fits with users expectations,
doesn't break the current release practice and comes within the acceptable
time frame is professionally accountable.
Anatol
Am 03.12.2015 um 11:44 schrieb Anatol Belski:
IMHO offering a secure release which also fits with users expectations
I would agree if this were about the release itself, PHP's sourcecode.
It is not. It is about a binary. But I will shut up now.
Am 03.12.2015 um 11:44 schrieb Anatol Belski:
IMHO offering a secure release which also fits with users expectations
I would agree if this were about the release itself, PHP's sourcecode.
It is not. It is about a binary. But I will shut up now.
In my world, we build softwares from sources, then we may found
issues. We patch the sources to fix them and make everything work
together smoothly.
In other words, either we totally failed to explain the QA part of
this process or you focus mainly on "windows blah, windows there" part
of this thing. And that windows is and always been part of the release
process is nothing new. Yes, 7 is big, but that should not affect the
quality of our releases, the sources and the ability to use these
sources with the libraries out there.
Cheers,
Pierre
@pierrejoye | http://www.libgd.org
Am 03.12.2015 um 12:10 schrieb Pierre Joye:
In my world, we build softwares from sources, then we may found
issues. We patch the sources to fix them and make everything work
together smoothly.
Are you suggesting that PHP 7.0.0 will be changed, re-tagged, and then
released without a new release candidate if you find a problem building
it for Windows?
Am 03.12.2015 um 12:10 schrieb Pierre Joye:
In my world, we build softwares from sources, then we may found
issues. We patch the sources to fix them and make everything work
together smoothly.Are you suggesting that PHP 7.0.0 will be changed, re-tagged, and then
released without a new release candidate if you find a problem building
it for Windows?
Can you at least give me the illusion that you read our answers? It is
not only about windows.
I think it is confusing enough without trying to add more
"suggestions" to the stack.
What I am saying is simple. Openssl will release security related
fixes today. Most if not all of them will hit 3rd party
packagers/distros today/tomorrow/soon. Now, after discussions, waiting
a couple of hours more sounds like a sane (if not only) move to ensure
that everything goes well with openssl and php 7. If that's not the
case, for example openssl breaks BC again, then it is a problem in
openssl and they should delay their release or distros/3rd parties
will delay the patches. It won't have an impact on today planed
release of php 7.
Le 03/12/2015 12:28, Pierre Joye a écrit :
Am 03.12.2015 um 12:10 schrieb Pierre Joye:
In my world, we build softwares from sources, then we may found
issues. We patch the sources to fix them and make everything work
together smoothly.
Are you suggesting that PHP 7.0.0 will be changed, re-tagged, and then
released without a new release candidate if you find a problem building
it for Windows?
Can you at least give me the illusion that you read our answers? It is
not only about windows.I think it is confusing enough without trying to add more
"suggestions" to the stack.What I am saying is simple. Openssl will release security related
fixes today. Most if not all of them will hit 3rd party
packagers/distros today/tomorrow/soon. Now, after discussions, waiting
a couple of hours more sounds like a sane (if not only) move to ensure
that everything goes well with openssl and php 7. If that's not the
case, for example openssl breaks BC again, then it is a problem in
openssl and they should delay their release or distros/3rd parties
will delay the patches. It won't have an impact on today planed
release of php 7.
For subsequent important releases, could we introduce a concept of
'frozen zone' of one or two days before the planned release date. This
is a time where everything is ready to deliver and nothing is planned.
Any event during this time delays the date. That's one of the mechanisms
NASA has established to respect launch times and I find it quite efficient.
Le 03/12/2015 12:28, Pierre Joye a écrit :
On Thu, Dec 3, 2015 at 6:14 PM, Sebastian Bergmann sebastian@php.net
wrote:Am 03.12.2015 um 12:10 schrieb Pierre Joye:
In my world, we build softwares from sources, then we may found
issues. We patch the sources to fix them and make everything work
together smoothly.
Are you suggesting that PHP 7.0.0 will be changed, re-tagged, and then
released without a new release candidate if you find a problem building
it for Windows?
Can you at least give me the illusion that you read our answers? It is
not only about windows.I think it is confusing enough without trying to add more
"suggestions" to the stack.What I am saying is simple. Openssl will release security related
fixes today. Most if not all of them will hit 3rd party
packagers/distros today/tomorrow/soon. Now, after discussions, waiting
a couple of hours more sounds like a sane (if not only) move to ensure
that everything goes well with openssl and php 7. If that's not the
case, for example openssl breaks BC again, then it is a problem in
openssl and they should delay their release or distros/3rd parties
will delay the patches. It won't have an impact on today planed
release of php 7.For subsequent important releases, could we introduce a concept of 'frozen
zone' of one or two days before the planned release date.
That concept already exists. See line 11 and 12 (second item!!) at
http://git.php.net/?p=php-src.git;a=blob;f=README.RELEASE_PROCESS
cheers,
Derick
Hi,
guys, just go out and say to the public, that due to Openssl security
fixes which are awaited and thus because we want to ensure that 7.0.0.
will be correctly working with it, we won't release 7.0.0 even as source
until we are sure the QA procedure is gone.
PHP can get really good bashing for being too hasty out of the door not
working with latest and secure OpenSSL.
You know me, I am far from a Windows fan, it makes just send. The
Openssl update is force majeure.
Best,
Andrey
Le 03/12/2015 12:28, Pierre Joye a écrit :
On Thu, Dec 3, 2015 at 6:14 PM, Sebastian Bergmann sebastian@php.net
wrote:Am 03.12.2015 um 12:10 schrieb Pierre Joye:
In my world, we build softwares from sources, then we may found
issues. We patch the sources to fix them and make everything work
together smoothly.
Are you suggesting that PHP 7.0.0 will be changed, re-tagged, and then
released without a new release candidate if you find a problem
building
it for Windows?
Can you at least give me the illusion that you read our answers? It is
not only about windows.I think it is confusing enough without trying to add more
"suggestions" to the stack.What I am saying is simple. Openssl will release security related
fixes today. Most if not all of them will hit 3rd party
packagers/distros today/tomorrow/soon. Now, after discussions, waiting
a couple of hours more sounds like a sane (if not only) move to ensure
that everything goes well with openssl and php 7. If that's not the
case, for example openssl breaks BC again, then it is a problem in
openssl and they should delay their release or distros/3rd parties
will delay the patches. It won't have an impact on today planed
release of php 7.For subsequent important releases, could we introduce a concept of
'frozen zone' of one or two days before the planned release date. This
is a time where everything is ready to deliver and nothing is planned.
Any event during this time delays the date. That's one of the mechanisms
NASA has established to respect launch times and I find it quite efficient.
Le 03/12/2015 12:28, Pierre Joye a écrit :
On Thu, Dec 3, 2015 at 6:14 PM, Sebastian Bergmann sebastian@php.net
wrote:Am 03.12.2015 um 12:10 schrieb Pierre Joye:
In my world, we build softwares from sources, then we may found
issues. We patch the sources to fix them and make everything work
together smoothly.Are you suggesting that PHP 7.0.0 will be changed, re-tagged, and then
released without a new release candidate if you find a problem
building
it for Windows?Can you at least give me the illusion that you read our answers? It is
not only about windows.I think it is confusing enough without trying to add more
"suggestions" to the stack.What I am saying is simple. Openssl will release security related
fixes today. Most if not all of them will hit 3rd party
packagers/distros today/tomorrow/soon. Now, after discussions, waiting
a couple of hours more sounds like a sane (if not only) move to ensure
that everything goes well with openssl and php 7. If that's not the
case, for example openssl breaks BC again, then it is a problem in
openssl and they should delay their release or distros/3rd parties
will delay the patches. It won't have an impact on today planed
release of php 7.For subsequent important releases, could we introduce a concept of
'frozen zone' of one or two days before the planned release date. This is a
time where everything is ready to deliver and nothing is planned. Any event
during this time delays the date. That's one of the mechanisms NASA has
established to respect launch times and I find it quite efficient.
We do have that already. What is happening now has been done many times in
the last decade.
Please move on. 7 is getting out today.
QA and ready builds are important, but why is it tagged after all if it
might be retagged if any issues occur? Why isn't it frozen to a specific
commit but not tagged (via a public pushed tag) until everything is ready?
I understand that people really want PHP 7, but let's get it out
professionally with the release process as always.
Regards, Niklas
Hi Sebastian,
-----Original Message-----
From: Sebastian Bergmann [mailto:sebastian@php.net]
Sent: Thursday, December 3, 2015 11:59 AM
To: internals@lists.php.net
Subject: Re: [PHP-DEV] PHP 7.0.0 final RTM delayAm 03.12.2015 um 11:44 schrieb Anatol Belski:
IMHO offering a secure release which also fits with users expectations
I would agree if this were about the release itself, PHP's sourcecode.
It is not. It is about a binary. But I will shut up now.
I'm just not sure why the release process has to be discussed right at the
moment and why you ask me to throw away everything how it is being done in
that release process that is not defined by me but proven to bring success
and is being done for long time. If you have concerns and suggestions to the
release process, please initiate a discussion about it ASAP. But please
don't ask me to change the planned steps right at the second, it is
inconvenient and won't happen because it won't lead to anything good for the
release itself.
Thanks
Anatol
Hi Sebastian,
-----Original Message-----
From: Sebastian Bergmann [mailto:sebastian@php.net]
Sent: Thursday, December 3, 2015 6:51 AM
To: internals@lists.php.net
Subject: Re: [PHP-DEV] PHP 7.0.0 final RTM delayAm 02.12.2015 um 09:42 schrieb Anatol Belski:
Do the Windows builds have to be available immediately when the
sources of PHP 7.0.0 are released?
Yes.http://git.php.net/?p=php-src.git;a=blob;f=README.RELEASE_PROCESS
currently reads"Ensure that Windows builds will work before packaging"
in the "General notes and tips" section and then later in the "Rolling a
stable
release" section"Once the release has been tagged, contact the PHP Windows
development team (internals-win@lists.php.net) so that Windows
binaries can be created."I do not think that this means that the release of the source tarball
must wait
for the availability of the Windows binaries.
In fact, step 2g of "Getting the stable release announced" explains what
to do
when the Windows binaries are not available at the time of release.Please do not get me wrong: I appreciate what Microsoft in general and
you,
Anatol, as well as Pierre in particular have done for PHP.
But no vendor -- neither Microsoft nor Red Hat nor whoever else rolls
binary
distributions of PHP -- should have the power to delay a release in my
opinion.
Thanks for your notes.
I lean on the current practice, which is indeed continues already for some
years, that we deliver the whole set of packages prior the release
announcement. The RELEASE_PROCESS document is unfortunately not 100% in sync
with everything. But indeed I cannot remember a case where a release were
done without the care about the eco system. Particularly Windows packages
are being linked directly from the release announcement for a while. Users
know that and depend explicitly on us telling - release ready, you can use
it. Lucky RedHat users have Remi's repo then :)
At the end of the day, the release is made for the users. Most of users
won't even think about building from sources. It would sound really weird to
send a release which is unavailable to big mass of them today, even for a
release with less importance. And especially with the 7.0.0 matter, where
people was telling they'll even take it right at the day zero. But even if
not - doing so would move some of users into the second class suddenly,
quite rightless.
I would just ask for some patience, as mentioned before - today by UTC the
announcement is going out. It is still December 3rd as planned. That's why I
was sending the awareness about the late UTC afternoon today.
Thanks
Anatol
I would just ask for some patience, as mentioned before - today by UTC the
announcement is going out. It is still December 3rd as planned. That's why I
was sending the awareness about the late UTC afternoon today.
Anatol,
We're not dealing with tax forms that have to make it in by midnight UTC but rather with humans. Humans who are very excited and literally can't wait to celebrate the release of PHP - a lot more so as an event than necessarily downloading and installing it right away (if that's what they cared about they could do it already).
Releasing it now would mean most of the world gets to actually celebrate it on Dec 3rd, instead of turning it into a frustrating waiting day. I find it hard to imagine people having an issue with us saying the Windows binaries would be coming soon. That's why all in all, I think it's a mistake not to push it out as early in the day as possible, in other words - now.
I also think that in general we shouldn't wait with source releases for binary release - but specifically in this case, it's too minor a thing in my opinion to delay a historical release like that of PHP 7.0.0.
My 2c.
Zeev
Hi Zeev,
I would just ask for some patience, as mentioned before - today by UTC the
announcement is going out. It is still December 3rd as planned. That's why I
was sending the awareness about the late UTC afternoon today.Anatol,
We're not dealing with tax forms that have to make it in by midnight UTC but rather with humans. Humans who are very excited and literally can't wait to celebrate the release of PHP - a lot more so as an event than necessarily downloading and installing it right away (if that's what they cared about they could do it already).
Releasing it now would mean most of the world gets to actually celebrate it on Dec 3rd, instead of turning it into a frustrating waiting day. I find it hard to imagine people having an issue with us saying the Windows binaries would be coming soon. That's why all in all, I think it's a mistake not to push it out as early in the day as possible, in other words - now.
I also think that in general we shouldn't wait with source releases for binary release - but specifically in this case, it's too minor a thing in my opinion to delay a historical release like that of PHP 7.0.0.
The releases must be kept on hold until these binaries (and other are
done in the same time btw) are validated. See it as part of the QA. As
Remi mentioned, many issues have be caught during this process. If it
was only about delivering binaries, a day later will never be a
problem. But it is not the case. The case we are referring toi is to
avoid to have to do a fast patch release to work around an issue we
could have seen by validating the binaries.Simple.
--
Pierre
@pierrejoye | http://www.libgd.org
Le 03/12/2015 11:17, Pierre Joye a écrit :
The releases must be kept on hold until these binaries (and other are
done in the same time btw) are validated. See it as part of the QA. As
Remi mentioned, many issues have be caught during this process. If it
was only about delivering binaries, a day later will never be a
problem. But it is not the case. The case we are referring toi is to
avoid to have to do a fast patch release to work around an issue we
could have seen by validating the binaries.Simple.
I understand your pov and I agree that windows binaries should be ready
when announcing the release. But, IMO, everything should have been
'frozen' 2 or 3 days ago and a new openssl release or any other 3rd
party software, even tagged 'security fixes' shouldn't have disturbed
the process. Or the change is hot enough to delay the date again, but
that's another process.
Sorry to say that, as it doesn't remove anything to my respect for the
huge work you did, but It's now Dec, 4th in more and more locations in
the world and PHP 7 is not released yet ! Zeev is right, nobody cares
about UTC in such case.
Regards
François
On Thu, Dec 3, 2015 at 12:13 PM, François Laupretre francois@php.net
wrote:
Le 03/12/2015 11:17, Pierre Joye a écrit :
The releases must be kept on hold until these binaries (and other are
done in the same time btw) are validated. See it as part of the QA. As Remi
mentioned, many issues have be caught during this process. If it was only
about delivering binaries, a day later will never be a problem. But it is
not the case. The case we are referring toi is to avoid to have to do a
fast patch release to work around an issue we could have seen by validating
the binaries.Simple.I understand your pov and I agree that windows binaries should be ready
when announcing the release. But, IMO, everything should have been 'frozen'
2 or 3 days ago and a new openssl release or any other 3rd party software,
even tagged 'security fixes' shouldn't have disturbed the process. Or the
change is hot enough to delay the date again, but that's another process.Sorry to say that, as it doesn't remove anything to my respect for the
huge work you did, but It's now Dec, 4th in more and more locations in the
world and PHP 7 is not released yet ! Zeev is right, nobody cares about UTC
in such case.
Yeah, and if we released a couple of hours ago there would be places where
it was still dec 2.
I can remember at least 3 similar occasion when an openssl release was
coming the same day as our release and we have always waited for the
windows builds, I don't even remember any arguments about that.
As others mentioned waiting for the windows builds are not mandatory, so if
the windows build team would be slacking off or going MIA we could just
ignore it and push the release, but I don't think that the current
situation would warrant ignoring our standard procedure used for years.
my two cents.
--
Ferenc Kovács
@Tyr43l - http://tyrael.hu
On Thu, Dec 3, 2015 at 12:13 PM, François Laupretre francois@php.net
wrote:Le 03/12/2015 11:17, Pierre Joye a écrit :
The releases must be kept on hold until these binaries (and other are
done in the same time btw) are validated. See it as part of the QA. As Remi
mentioned, many issues have be caught during this process. If it was only
about delivering binaries, a day later will never be a problem. But it is
not the case. The case we are referring toi is to avoid to have to do a
fast patch release to work around an issue we could have seen by validating
the binaries.Simple.I understand your pov and I agree that windows binaries should be ready
when announcing the release. But, IMO, everything should have been 'frozen'
2 or 3 days ago and a new openssl release or any other 3rd party software,
even tagged 'security fixes' shouldn't have disturbed the process. Or the
change is hot enough to delay the date again, but that's another process.Sorry to say that, as it doesn't remove anything to my respect for the
huge work you did, but It's now Dec, 4th in more and more locations in the
world and PHP 7 is not released yet ! Zeev is right, nobody cares about UTC
in such case.Yeah, and if we released a couple of hours ago there would be places where
it was still dec 2.
I can remember at least 3 similar occasion when an openssl release was
coming the same day as our release and we have always waited for the
windows builds, I don't even remember any arguments about that.
As others mentioned waiting for the windows builds are not mandatory, so if
the windows build team would be slacking off or going MIA we could just
ignore it and push the release, but I don't think that the current
situation would warrant ignoring our standard procedure used for years.
+1 . We've always followed this path , but now it is PHP 7 majors release,
some people here seem to discover the RM processing and try to change it
to urge things.
Please, respect each other's work , and if we want to change something
in RM processing, then just start a discussion about it.
I remember in 5.5 RMing having to wait for WIndows builds (OpenSSL related,
or not), and delayed the announcement of the release by +1 day.
This has happened already.
Julien.Pauli
Hi Zeev,
-----Original Message-----
From: Zeev Suraski [mailto:zeev@zend.com]
Sent: Thursday, December 3, 2015 9:55 AM
To: Anatol Belski anatol.php@belski.net
Cc: Sebastian Bergmann sebastian@php.net; internals@lists.php.net
Subject: Re: [PHP-DEV] PHP 7.0.0 final RTM delayI would just ask for some patience, as mentioned before - today by UTC
the announcement is going out. It is still December 3rd as planned.
That's why I was sending the awareness about the late UTC afternoon today.Anatol,
We're not dealing with tax forms that have to make it in by midnight UTC but
rather with humans. Humans who are very excited and literally can't wait to
celebrate the release of PHP - a lot more so as an event than necessarily
downloading and installing it right away (if that's what they cared about they
could do it already).Releasing it now would mean most of the world gets to actually celebrate it on
Dec 3rd, instead of turning it into a frustrating waiting day. I find it hard to
imagine people having an issue with us saying the Windows binaries would be
coming soon. That's why all in all, I think it's a mistake not to push it out as early
in the day as possible, in other words - now.I also think that in general we shouldn't wait with source releases for binary
release - but specifically in this case, it's too minor a thing in my opinion to delay
a historical release like that of PHP 7.0.0.My 2c.
My red wine is already cooling for two days, your preferential drink for sure, too. The moment is big. But how human it wants ever to be, it is hardly applicable to the the job of delivering a release, even today. We should not let us to hype but do a solid delivery with everything that belongs to it at the current time. Acting any other way can get dangerous in the technical perspective and specifically today it would be explicitly unfair to a part of the community. Both things are bad. That's why I would prefer rather to keep the heads cold and to follow the process that is proven to deliver successful releases, then we can be sure others have a real reason to overhype.
Regards
Anatol
Den 2015-12-03 kl. 11:44, skrev Anatol Belski:
Hi Zeev,
-----Original Message-----
From: Zeev Suraski [mailto:zeev@zend.com]
Sent: Thursday, December 3, 2015 9:55 AM
To: Anatol Belski anatol.php@belski.net
Cc: Sebastian Bergmann sebastian@php.net; internals@lists.php.net
Subject: Re: [PHP-DEV] PHP 7.0.0 final RTM delayI would just ask for some patience, as mentioned before - today by UTC
the announcement is going out. It is still December 3rd as planned.
That's why I was sending the awareness about the late UTC afternoon today.Anatol,
We're not dealing with tax forms that have to make it in by midnight UTC but
rather with humans. Humans who are very excited and literally can't wait to
celebrate the release of PHP - a lot more so as an event than necessarily
downloading and installing it right away (if that's what they cared about they
could do it already).Releasing it now would mean most of the world gets to actually celebrate it on
Dec 3rd, instead of turning it into a frustrating waiting day. I find it hard to
imagine people having an issue with us saying the Windows binaries would be
coming soon. That's why all in all, I think it's a mistake not to push it out as early
in the day as possible, in other words - now.I also think that in general we shouldn't wait with source releases for binary
release - but specifically in this case, it's too minor a thing in my opinion to delay
a historical release like that of PHP 7.0.0.My 2c.
My red wine is already cooling for two days, your preferential drink for sure, too. The moment is big. But how human it wants ever to be, it is hardly applicable to the the job of delivering a release, even today. We should not let us to hype but do a solid delivery with everything that belongs to it at the current time. Acting any other way can get dangerous in the technical perspective and specifically today it would be explicitly unfair to a part of the community. Both things are bad. That's why I would prefer rather to keep the heads cold and to follow the process that is proven to deliver successful releases, then we can be sure others have a real reason to overhype.
Regards
Anatol
Having some red wine on the cooling seems like a very good idea,
especially in combination with a cool head ;-). And thanks for a
very professional job getting #PHP7 out of the door!
Regards //Björn Larsson
My red wine is already cooling for two days, your preferential drink for
sure,
too. The moment is big. But how human it wants ever to be, it is hardly
applicable to the the job of delivering a release, even today. We should
not
let us to hype but do a solid delivery with everything that belongs to it
at the
current time. Acting any other way can get dangerous in the technical
perspective and specifically today it would be explicitly unfair to a part
of
the community. Both things are bad. That's why I would prefer rather to
keep the heads cold and to follow the process that is proven to deliver
successful releases, then we can be sure others have a real reason to
overhype.
Anatol,
I'm sorry, but this has nothing to do with professionalism or coolness of
wine nor heads, and to be perfectly honest, I'm not feeling very comfortable
with the suggestion otherwise. Your choice, while completely valid, is not
an ounce more professional or cool headed than the alternative.
What leads me to think your choice is wrong are two things:
- The fact that generally speaking, binary builds are not supposed to be a
blocker for a PHP release - which has always been about source (and should
continue being about source). - Taking into to account that we don't live in a world of machines, but
humans. Staying cool headed is not equal as ignoring thoughts and feelings
of users.
As an extra bonus, the issue itself is hardly the material of which delays
are supposed to be made. The official builds of PHP for the versions that's
likely to be used by anybody who might actually be vulnerable to these
issues - 5.6.16 and 5.5.30 - contain this (non-critical) vulnerability and
to the best of my knowledge we're not going to be updating them. And if we
are, what's blocking us from doing the same with 7.0.0?
Either way, I'm not going to continue convincing you. I'm not arguing it's
your call. I was important for me to make it clear that this is not about
professionalism nor about temperature levels of any sorts.
Thanks,
Zeev
My red wine is already cooling for two days, your preferential drink for
sure,
too. The moment is big. But how human it wants ever to be, it is hardly
applicable to the the job of delivering a release, even today. We should
not
let us to hype but do a solid delivery with everything that belongs to it
at the
current time. Acting any other way can get dangerous in the technical
perspective and specifically today it would be explicitly unfair to a
part
of
the community. Both things are bad. That's why I would prefer rather to
keep the heads cold and to follow the process that is proven to deliver
successful releases, then we can be sure others have a real reason to
overhype.Anatol,
I'm sorry, but this has nothing to do with professionalism or coolness of
wine nor heads, and to be perfectly honest, I'm not feeling very
comfortable
with the suggestion otherwise. Your choice, while completely valid, is not
an ounce more professional or cool headed than the alternative.
let's just stop this here.
as already mentioned this is how we are doing the release process for
years, if you have a problem with that, you are free to make suggestions or
initiate discussion.
but what you guys are doing seems to be coercing the current RM to get your
way in the last minute.
Anatol mentioned the openssl depencency for the windows builds to the RMs
two days ago and even sent a headsup email to internals (this thread).
we didn't make a promise on the exact hour of the release and we aren't
late yet, I don't think that there is a need for "desperate" measures or
getting into personal attacks.
everything is going according to the plan.
--
Ferenc Kovács
@Tyr43l - http://tyrael.hu
-----Original Message-----
From: Ferenc Kovacs [mailto:tyra3l@gmail.com]
Sent: Thursday, December 03, 2015 2:25 PM
To: Zeev Suraski
Cc: Anatol Belski; Sebastian Bergmann; PHP Internals
Subject: Re: [PHP-DEV] PHP 7.0.0 final RTM delayMy red wine is already cooling for two days, your preferential drink
for
sure,
too. The moment is big. But how human it wants ever to be, it is
hardly
applicable to the the job of delivering a release, even today. We
should
not
let us to hype but do a solid delivery with everything that belongs
to it
at the
current time. Acting any other way can get dangerous in the
technical
perspective and specifically today it would be explicitly unfair to a
part
of
the community. Both things are bad. That's why I would prefer
rather to
keep the heads cold and to follow the process that is proven to
deliver
successful releases, then we can be sure others have a real reason
to
overhype.Anatol,
I'm sorry, but this has nothing to do with professionalism or coolness
of
wine nor heads, and to be perfectly honest, I'm not feeling very
comfortable
with the suggestion otherwise. Your choice, while completely valid,
is not
an ounce more professional or cool headed than the alternative.let's just stop this here.
as already mentioned this is how we are doing the release process for
years,
if you have a problem with that, you are free to make suggestions or
initiate
discussion.
but what you guys are doing seems to be coercing the current RM to get
your
way in the last minute.
Anatol mentioned the openssl depencency for the windows builds to the
RMs two days ago and even sent a headsup email to internals (this thread).we didn't make a promise on the exact hour of the release and we aren't
late
yet, I don't think that there is a need for "desperate" measures or
getting
into personal attacks.
everything is going according to the plan.
Ferenc,
I’m not sure what to say. I was quoting Anatol’s own words to me, I even
refrained from categorizing them as an attack – and still you’re saying I’m
attacking him? The discussion went off-track as soon as professionalism and
temperatures were introduced to it.
I’m not trying to coerce the RM to do anything. At this point I’m not even
trying to convince him. Earlier, I did try to convince him why I think he’s
taken a wrong decision, but if you read my note – I outright said it’s his
call and that I’m no longer going to try and continue convincing him to
change his mind; The only reason I sent my note is that I did not want the
(bogus) portrayal of this decision as the only professional/cool headed one
to stick, because, well, it’s not true and worse, it's offensive. The
decision to delay is his own, valid, subjective decision – which is fine,
but that’s it.
Zeev
Hi Zeev,
-----Original Message-----
From: Zeev Suraski [mailto:zeev@zend.com]
Sent: Thursday, December 3, 2015 1:09 PM
To: Anatol Belski anatol.php@belski.net
Cc: Sebastian Bergmann sebastian@php.net; internals@lists.php.net
Subject: RE: [PHP-DEV] PHP 7.0.0 final RTM delayMy red wine is already cooling for two days, your preferential drink
for sure, too. The moment is big. But how human it wants ever to be,
it is hardly applicable to the the job of delivering a release, even
today. We should not let us to hype but do a solid delivery with
everything that belongs to it at the current time. Acting any other
way can get dangerous in the technical perspective and specifically
today it would be explicitly unfair to a part of the community. Both
things are bad. That's why I would prefer rather to keep the heads
cold and to follow the process that is proven to deliver successful
releases, then we can be sure others have a real reason to overhype.Anatol,
I'm sorry, but this has nothing to do with professionalism or coolness of wine
nor heads, and to be perfectly honest, I'm not feeling very comfortable with the
suggestion otherwise. Your choice, while completely valid, is not an ounce more
professional or cool headed than the alternative.What leads me to think your choice is wrong are two things:
- The fact that generally speaking, binary builds are not supposed to be a
blocker for a PHP release - which has always been about source (and should
continue being about source).- Taking into to account that we don't live in a world of machines, but humans.
Staying cool headed is not equal as ignoring thoughts and feelings of users.As an extra bonus, the issue itself is hardly the material of which delays are
supposed to be made. The official builds of PHP for the versions that's likely to
be used by anybody who might actually be vulnerable to these issues - 5.6.16
and 5.5.30 - contain this (non-critical) vulnerability and to the best of my
knowledge we're not going to be updating them. And if we are, what's blocking
us from doing the same with 7.0.0?Either way, I'm not going to continue convincing you. I'm not arguing it's your
call. I was important for me to make it clear that this is not about
professionalism nor about temperature levels of any sorts.
What I just wanted to say by the temperature is that I'm as human as anyone else and hopefully allowed to hype not less than anyone else. However there are always people who celebrate and people who serve, those who serve have to keep the cold head. I'm serving, that's it. Hope this explains any possible mistaking on my words.
Regards
Anatol
What I just wanted to say by the temperature is that I'm as human as
anyone
else and hopefully allowed to hype not less than anyone else. However
there are always people who celebrate and people who serve, those who
serve have to keep the cold head. I'm serving, that's it. Hope this
explains
any possible mistaking on my words.
I agree with you 100% on that, and I certainly didn't imply you weren't
human :) On internals@, we're all in the business of serving, and when I,
Sebastian and others suggested they thought it was wrong to delay the
release - they were just as cool headed as you were - they just reached a
different conclusion.
Zeev
Is there an update on the OpenSSL front...?
Is this release of OpenSSL going to be binary compatible or just source
compatible?
They just released:
https://mta.openssl.org/pipermail/openssl-announce/2015-December/000049.html
Kaplan
Is there an update on the OpenSSL front...?
Is this release of OpenSSL going to be binary compatible or just source
compatible?
Le 03/12/2015 09:55, Zeev Suraski a écrit :
Releasing it now would mean most of the world gets to actually
celebrate it on Dec 3rd, instead of turning it into a frustrating
waiting day. I find it hard to imagine people having an issue with us
saying the Windows binaries would be coming soon. That's why all in
all, I think it's a mistake not to push it out as early in the day as
possible, in other words - now. I also think that in general we
shouldn't wait with source releases for binary release - but
specifically in this case, it's too minor a thing in my opinion to
delay a historical release like that of PHP 7.0.0. My 2c. Zeev
+1. It's 23:59 pm in Auckland, NZ now. The world has entered Dec, 4th.
François