What is the difference between "Windows Sources" and our official releases?
Did windows.php.net fork php or something? Embedded other things?
Are the binaries really not generated from the official sources?
This sounds like a horrible idea if true.
-Hannes
Commit: 9883c8f0bbcb64ad42ce66d694fffd848fc2ebcc
Author: Anatol Belski ab@php.net Mon, 15 Jun 2015 14:39:31 +0200
Parents: d7f7d44e25c4bb43de7696db47189026428daaac
Branches: masterLink: http://git.php.net/?p=web/php.git;a=commitdiff;h=9883c8f0bbcb64ad42ce66d694fffd848fc2ebcc
Log:
apply patch from bug #69829And, we probably should keep this wording in the next announcement
Bugs:
https://bugs.php.net/69829Changed paths:
M archive/entries/2015-06-11-3.xmlDiff:
diff --git a/archive/entries/2015-06-11-3.xml b/archive/entries/2015-06-11-3.xml
index 232dcee..be5d386 100644
--- a/archive/entries/2015-06-11-3.xml
+++ b/archive/entries/2015-06-11-3.xml
@@ -43,7 +43,7 @@<p> For source downloads of PHP 7.0.0 Alpha 1 please visit
the <a href="https://downloads.php.net/ab/">download page</a>, Windows binaries
the <a href="https://downloads.php.net/ab/">download page</a>, Windows sources and binaries can be found on <a href="http://windows.php.net/qa/">windows.php.net/qa/</a>. </p>--
PHP Webmaster List Mailing List (http://www.php.net/)
Hi Hannes,
Nope, it's the same source and the same tag is always used. The tag is the actual reference for any release. But usually people on Windows don't have things like tar,gz and others. Even if they have - the compatibility might be just bad. So it's zipped.
Regards
Anatol
-----Original Message-----
From: Hannes Magnusson [mailto:hannes.magnusson@gmail.com]
Sent: Monday, June 15, 2015 3:52 PM
To: Anatol Belski; PHP Development
Cc: PHP Webmaster ML
Subject: [PHP-DEV] PHP7 releases vs Windows Sources?What is the difference between "Windows Sources" and our official releases?
Did windows.php.net fork php or something? Embedded other things?
Are the binaries really not generated from the official sources?
This sounds like a horrible idea if true.-Hannes
Commit: 9883c8f0bbcb64ad42ce66d694fffd848fc2ebcc
Author: Anatol Belski ab@php.net Mon, 15 Jun 2015 14:39:31 +0200
Parents: d7f7d44e25c4bb43de7696db47189026428daaac
Branches: masterLink:
http://git.php.net/?p=web/php.git;a=commitdiff;h=9883c8f0bbcb64ad42ce66d6
94fffd848fc2ebccLog:
apply patch from bug #69829And, we probably should keep this wording in the next announcement
Bugs:
https://bugs.php.net/69829Changed paths:
M archive/entries/2015-06-11-3.xmlDiff:
diff --git a/archive/entries/2015-06-11-3.xml
b/archive/entries/2015-06-11-3.xml
index 232dcee..be5d386 100644
--- a/archive/entries/2015-06-11-3.xml
+++ b/archive/entries/2015-06-11-3.xml
@@ -43,7 +43,7 @@<p> For source downloads of PHP 7.0.0 Alpha 1 please visit
the <a href="https://downloads.php.net/ab/">download page</a>,Windows binaries
the <a href="https://downloads.php.net/ab/">download page</a>,- Windows sources and binaries
can be found on <a href="http://windows.php.net/qa/">windows.php.net/qa/</a>;.
</p>--
PHP Webmaster List Mailing List (http://www.php.net/) To unsubscribe,
visit: http://www.php.net/unsub.php--
To unsubscribe, visit:
http://www.php.net/unsub.php
Then this fix doesn't make any sense -- you are saying if I download
the .tar.gz and .zip and extract those two, I will have precisely the
same sources?
Then this fix should be reverted as there is isn't any special Windows
Sources and the official releases should work just fine.
-Hannes
Hi Hannes,
Nope, it's the same source and the same tag is always used. The tag is the actual reference for any release. But usually people on Windows don't have things like tar,gz and others. Even if they have - the compatibility might be just bad. So it's zipped.
Regards
Anatol
-----Original Message-----
From: Hannes Magnusson [mailto:hannes.magnusson@gmail.com]
Sent: Monday, June 15, 2015 3:52 PM
To: Anatol Belski; PHP Development
Cc: PHP Webmaster ML
Subject: [PHP-DEV] PHP7 releases vs Windows Sources?What is the difference between "Windows Sources" and our official releases?
Did windows.php.net fork php or something? Embedded other things?
Are the binaries really not generated from the official sources?
This sounds like a horrible idea if true.-Hannes
Commit: 9883c8f0bbcb64ad42ce66d694fffd848fc2ebcc
Author: Anatol Belski ab@php.net Mon, 15 Jun 2015 14:39:31 +0200
Parents: d7f7d44e25c4bb43de7696db47189026428daaac
Branches: masterLink:
http://git.php.net/?p=web/php.git;a=commitdiff;h=9883c8f0bbcb64ad42ce66d6
94fffd848fc2ebccLog:
apply patch from bug #69829And, we probably should keep this wording in the next announcement
Bugs:
https://bugs.php.net/69829Changed paths:
M archive/entries/2015-06-11-3.xmlDiff:
diff --git a/archive/entries/2015-06-11-3.xml
b/archive/entries/2015-06-11-3.xml
index 232dcee..be5d386 100644
--- a/archive/entries/2015-06-11-3.xml
+++ b/archive/entries/2015-06-11-3.xml
@@ -43,7 +43,7 @@<p> For source downloads of PHP 7.0.0 Alpha 1 please visit
the <a href="https://downloads.php.net/ab/">download page</a>,Windows binaries
the <a href="https://downloads.php.net/ab/">download page</a>,- Windows sources and binaries
can be found on <a href="http://windows.php.net/qa/">windows.php.net/qa/</a>;.
</p>--
PHP Webmaster List Mailing List (http://www.php.net/) To unsubscribe,
visit: http://www.php.net/unsub.php--
To unsubscribe, visit:
http://www.php.net/unsub.php
Hannes Magnusson wrote:
Then this fix doesn't make any sense -- you are saying if I download
the .tar.gz and .zip and extract those two, I will have precisely the
same sources?
Then this fix should be reverted as there is isn't any special Windows
Sources and the official releases should work just fine.
There is some difference (timestamps?) which causes building from the
tarred sources to fail on Windows (see bug #69829). Furthermore
extracting the tarred sources with 7zip (which seems to be a pretty
common archiver) results in spurious PaxHeaders.##### directories, what
is bug in 7zip[1], and doesn't really affect the build, but is confusing
nonetheless (and requires more disk space).
At least until these issue are solved, IMO it's better to link to the
"Windows" sources packaged as .zip.
[1] http://sourceforge.net/p/sevenzip/bugs/1413/
--
Christoph M. Becker
Hannes Magnusson wrote:
Then this fix doesn't make any sense -- you are saying if I download
the .tar.gz and .zip and extract those two, I will have precisely the
same sources?
Then this fix should be reverted as there is isn't any special Windows
Sources and the official releases should work just fine.There is some difference (timestamps?) which causes building from the
tarred sources to fail on Windows (see bug #69829).
"touching" generated files as part of the packaging process is a good
idea for all platforms.
Furthermore
extracting the tarred sources with 7zip (which seems to be a pretty
common archiver) results in spurious PaxHeaders.##### directories, what
is bug in 7zip[1], and doesn't really affect the build, but is confusing
nonetheless (and requires more disk space).At least until these issue are solved, IMO it's better to link to the
"Windows" sources packaged as .zip.
If there is a need for zip archives I'd put them next to tar.gz etc. and
distribute them via our mirror network.
johannes
Hi Johannes,
-----Original Message-----
From: Johannes Schlüter [mailto:johannes@schlueters.de]
Sent: Monday, June 15, 2015 4:52 PM
To: Christoph Becker
Cc: Hannes Magnusson; Anatol Belski; PHP Development; PHP Webmaster ML
Subject: Re: [PHP-DEV] PHP7 releases vs Windows Sources?Hannes Magnusson wrote:
Then this fix doesn't make any sense -- you are saying if I download
the .tar.gz and .zip and extract those two, I will have precisely
the same sources?
Then this fix should be reverted as there is isn't any special
Windows Sources and the official releases should work just fine.There is some difference (timestamps?) which causes building from the
tarred sources to fail on Windows (see bug #69829)."touching" generated files as part of the packaging process is a good idea for all
platforms.Furthermore
extracting the tarred sources with 7zip (which seems to be a pretty
common archiver) results in spurious PaxHeaders.##### directories,
what is bug in 7zip[1], and doesn't really affect the build, but is
confusing nonetheless (and requires more disk space).At least until these issue are solved, IMO it's better to link to the
"Windows" sources packaged as .zip.If there is a need for zip archives I'd put them next to tar.gz etc. and distribute
them via our mirror network.
Yep, this could work and were probably proper solution. Except we wouldn't add some issue for the non Windows users :) I'm not sure, why is it done so ATM, probably it has its historical reasons. But this would probably cause us need to update the release process procedure? And, for PHP7 or for any other as well? Currently that zipball is just generated with the build process, so it'll need to be sent over somehow. Were anyway doable, wondering what the other RMs would say. Frankly, I'd leave it as it is - as long as it's reachable and documented.
Regards
Anatol
Hi Johannes,
-----Original Message-----
From: Johannes Schlüter [mailto:johannes@schlueters.de]
Sent: Monday, June 15, 2015 4:52 PM
To: Christoph Becker
Cc: Hannes Magnusson; Anatol Belski; PHP Development; PHP Webmaster ML
Subject: Re: [PHP-DEV] PHP7 releases vs Windows Sources?Hannes Magnusson wrote:
Then this fix doesn't make any sense -- you are saying if I download
the .tar.gz and .zip and extract those two, I will have precisely
the same sources?
Then this fix should be reverted as there is isn't any special
Windows Sources and the official releases should work just fine.There is some difference (timestamps?) which causes building from the
tarred sources to fail on Windows (see bug #69829)."touching" generated files as part of the packaging process is a good
idea for all
platforms.Furthermore
extracting the tarred sources with 7zip (which seems to be a pretty
common archiver) results in spurious PaxHeaders.##### directories,
what is bug in 7zip[1], and doesn't really affect the build, but is
confusing nonetheless (and requires more disk space).At least until these issue are solved, IMO it's better to link to the
"Windows" sources packaged as .zip.If there is a need for zip archives I'd put them next to tar.gz etc.
and distribute
them via our mirror network.Yep, this could work and were probably proper solution. Except we
wouldn't add some issue for the non Windows users :) I'm not sure, why is
it done so ATM, probably it has its historical reasons. But this would
probably cause us need to update the release process procedure? And, for
PHP7 or for any other as well? Currently that zipball is just generated
with the build process, so it'll need to be sent over somehow. Were anyway
doable, wondering what the other RMs would say. Frankly, I'd leave it as
it is - as long as it's reachable and documented.
The reason is that we generate zip for binaries, and we just do the same
for the src, providing zip archives using the same naming convention.
We know many other tools relying on these zip, normalized URLs, so we must
keep them. It does not hurt anyone anyway.
As of fork, custom patches etc, there is no such thing.
Cheers,
Pierre
Yep, this could work and were probably proper solution. Except we
wouldn't add some issue for the non Windows users :) I'm not sure, why
is it done so ATM, probably it has its historical reasons. But this
would probably cause us need to update the release process procedure?
And, for PHP7 or for any other as well? Currently that zipball is just
generated with the build process, so it'll need to be sent over
somehow. Were anyway doable, wondering what the other RMs would say.
Frankly, I'd leave it as it is - as long as it's reachable and
documented.The reason is that we generate zip for binaries, and we just do the
same for the src, providing zip archives using the same naming
convention.We know many other tools relying on these zip, normalized URLs, so we
must keep them. It does not hurt anyone anyway.
As I said in early 5.3 times already: I'd love if we'd find a process
and layout to have a single source for all downloads and distribute all
downloads from our mirror network, not having Windows as second class
citizen somewhere else but via all ~70 mirrors.
Yes this would hurt short term as we'd have to change some processes and
yes it might change URLs (which can be solved via proper redirects) but
long term users get faster downloads and a single place to go with no
confusion like the one that started this thread.
johannes
On Wed, Jun 17, 2015 at 12:17 AM, Johannes Schlüter
johannes@schlueters.de wrote:
Yep, this could work and were probably proper solution. Except we
wouldn't add some issue for the non Windows users :) I'm not sure, why
is it done so ATM, probably it has its historical reasons. But this
would probably cause us need to update the release process procedure?
And, for PHP7 or for any other as well? Currently that zipball is just
generated with the build process, so it'll need to be sent over
somehow. Were anyway doable, wondering what the other RMs would say.
Frankly, I'd leave it as it is - as long as it's reachable and
documented.The reason is that we generate zip for binaries, and we just do the
same for the src, providing zip archives using the same naming
convention.We know many other tools relying on these zip, normalized URLs, so we
must keep them. It does not hurt anyone anyway.As I said in early 5.3 times already: I'd love if we'd find a process
and layout to have a single source for all downloads and distribute all
downloads from our mirror network, not having Windows as second class
citizen somewhere else but via all ~70 mirrors.Yes this would hurt short term as we'd have to change some processes and
yes it might change URLs (which can be solved via proper redirects) but
long term users get faster downloads and a single place to go with no
confusion like the one that started this thread.
That would me manageable. However as of now it is not possible to do
it. systems is hard to deal with as only a few access to one or the
other critical boxes, snaps being dead is one of the cases. If we do
it, we will also need the ability to do independent releases in case
we need to update one of the dependencies (not code change, only
provide updates for one or the other DLLs in case of critical security
issues).
Once the RMs automation tooling things are sorted out, I will be happy
to revisit the whole thing and see if we can have a better way to do
things.
Cheers,
Pierre
@pierrejoye | http://www.libgd.org
Pierre Joye in php.internals (Wed, 17 Jun 2015 06:07:14 +0700):
If we do it, we will also need the ability to do independent releases
in case we need to update one of the dependencies (not code change, only
provide updates for one or the other DLLs in case of critical security
issues).
YM, like libcurl right now.
Jan
Hi Johannes,
-----Original Message-----
From: Johannes Schlüter [mailto:johannes@schlueters.de]
Sent: Monday, June 15, 2015 4:52 PM
To: Christoph Becker
Cc: Hannes Magnusson; Anatol Belski; PHP Development; PHP Webmaster ML
Subject: Re: [PHP-DEV] PHP7 releases vs Windows Sources?Hannes Magnusson wrote:
Then this fix doesn't make any sense -- you are saying if I download
the .tar.gz and .zip and extract those two, I will have precisely
the same sources?
Then this fix should be reverted as there is isn't any special
Windows Sources and the official releases should work just fine.There is some difference (timestamps?) which causes building from the
tarred sources to fail on Windows (see bug #69829)."touching" generated files as part of the packaging process is a good idea for all
platforms.Furthermore
extracting the tarred sources with 7zip (which seems to be a pretty
common archiver) results in spurious PaxHeaders.##### directories,
what is bug in 7zip[1], and doesn't really affect the build, but is
confusing nonetheless (and requires more disk space).At least until these issue are solved, IMO it's better to link to the
"Windows" sources packaged as .zip.If there is a need for zip archives I'd put them next to tar.gz etc. and distribute
them via our mirror network.Yep, this could work and were probably proper solution. Except we wouldn't add some issue for the non Windows users :) I'm not sure, why is it done so ATM, probably it has its historical reasons. But this would probably cause us need to update the release process procedure? And, for PHP7 or for any other as well? Currently that zipball is just generated with the build process, so it'll need to be sent over somehow. Were anyway doable, wondering what the other RMs would say. Frankly, I'd leave it as it is - as long as it's reachable and documented.
Thats what we want. We want the official release balls to be generated
by an "official server" using the official toolchain.
There should never be a time when a Release Manager pulls up his
notebook, does a checkout and packages that and uploads. Its bad
enough we have this for pecl exts, but there is no reason for php-src
to be playing with fire and infiltration agencies.
That has unfortunately happened before, and resulted in us
distributing .orig files (patch conflicts), .exp, .out, .php, ...
(failed tests results) and even wrongly generated artifacts (due to
wrong bison/re2c versions installed locally).
We don't want that happen again.
The official releases should be done on "snap box", and be completely
automated with no room for accidents.
It produces several archives, and we can add .zip to that mix if not
already available.
It should be obvious that any binary distribution that aims to be
official PHP.net release should use this official release, not some
custom mix of things.
It is important that these official binaries also don't regenerate the
files in the archive.
If there is an extra file (.w32?), or touching of files, required to
make this archive usable to generate binaries from - then please fix
the root problem; touch the file before the packaging (and update the
README :)).
-Hannes
Hi Hannes,
-----Original Message-----
From: Hannes Magnusson [mailto:hannes.magnusson@gmail.com]
Sent: Monday, June 15, 2015 8:34 PM
To: Anatol Belski
Cc: Johannes Schlüter; Christoph Becker; PHP Development; PHP Webmaster ML
Subject: Re: [PHP-DEV] PHP7 releases vs Windows Sources?Hi Johannes,
-----Original Message-----
From: Johannes Schlüter [mailto:johannes@schlueters.de]
Sent: Monday, June 15, 2015 4:52 PM
To: Christoph Becker
Cc: Hannes Magnusson; Anatol Belski; PHP Development; PHP Webmaster
ML
Subject: Re: [PHP-DEV] PHP7 releases vs Windows Sources?Hannes Magnusson wrote:
Then this fix doesn't make any sense -- you are saying if I
download the .tar.gz and .zip and extract those two, I will have
precisely the same sources?
Then this fix should be reverted as there is isn't any special
Windows Sources and the official releases should work just fine.There is some difference (timestamps?) which causes building from
the tarred sources to fail on Windows (see bug #69829)."touching" generated files as part of the packaging process is a good
idea for all platforms.Furthermore
extracting the tarred sources with 7zip (which seems to be a pretty
common archiver) results in spurious PaxHeaders.##### directories,
what is bug in 7zip[1], and doesn't really affect the build, but is
confusing nonetheless (and requires more disk space).At least until these issue are solved, IMO it's better to link to
the "Windows" sources packaged as .zip.If there is a need for zip archives I'd put them next to tar.gz etc.
and distribute them via our mirror network.Yep, this could work and were probably proper solution. Except we wouldn't
add some issue for the non Windows users :) I'm not sure, why is it done so
ATM, probably it has its historical reasons. But this would probably cause us
need to update the release process procedure? And, for PHP7 or for any other as
well? Currently that zipball is just generated with the build process, so it'll need
to be sent over somehow. Were anyway doable, wondering what the other
RMs would say. Frankly, I'd leave it as it is - as long as it's reachable and
documented.Thats what we want. We want the official release balls to be generated by an
"official server" using the official toolchain.
There should never be a time when a Release Manager pulls up his notebook,
does a checkout and packages that and uploads. Its bad enough we have this for
pecl exts, but there is no reason for php-src to be playing with fire and
infiltration agencies.That has unfortunately happened before, and resulted in us distributing .orig
files (patch conflicts), .exp, .out, .php, ...
(failed tests results) and even wrongly generated artifacts (due to wrong
bison/re2c versions installed locally).We don't want that happen again.
The official releases should be done on "snap box", and be completely
automated with no room for accidents.
It produces several archives, and we can add .zip to that mix if not already
available.
It's a worthy goal IMHO. Currently it all is done manually as you know. The question is only - to implement it. And that's where I'm a wrong person to talk to. Technically I could do it, but for time (and other) reasons - I couldn't. Also I'm not the person who makes decisions about the infrastructure. snaps.php.net is currently offline fe, maybe something based on that could be it for the start, at least for the source packaging.
It should be obvious that any binary distribution that aims to be official PHP.net
release should use this official release, not some custom mix of things.
It is important that these official binaries also don't regenerate the files in the
archive.
If there is an extra file (.w32?), or touching of files, required to make this archive
usable to generate binaries from - then please fix the root problem; touch the
file before the packaging (and update the README :)).
I can just repeat - no char in the code and changed. And the reference is the tag. Also, as we know now, those zipballs are needed for some external tools. I'll check how the touching generated files can work, but I don't think it's solving the tools incompatibility issue (tar, gz, xz, 7zip, etc.) between Windows and *nix.
Hannes, I think you should address your concerns to the persons who actually induce. Such a global solution that you describe will probably require some consent, some good plan, material and human resources. I could help with implementation maybe, to some part. But right now, I think I'm more useful by doing the RM job and fixing bugs, so I should concentrate on that :) So I'm better out of this discussion.
Regards
Anatol
Hi Hannes,
-----Original Message-----
From: Hannes Magnusson [mailto:hannes.magnusson@gmail.com]
Sent: Monday, June 15, 2015 8:34 PM
To: Anatol Belski
Cc: Johannes Schlüter; Christoph Becker; PHP Development; PHP Webmaster ML
Subject: Re: [PHP-DEV] PHP7 releases vs Windows Sources?Hi Johannes,
-----Original Message-----
From: Johannes Schlüter [mailto:johannes@schlueters.de]
Sent: Monday, June 15, 2015 4:52 PM
To: Christoph Becker
Cc: Hannes Magnusson; Anatol Belski; PHP Development; PHP Webmaster
ML
Subject: Re: [PHP-DEV] PHP7 releases vs Windows Sources?Hannes Magnusson wrote:
Then this fix doesn't make any sense -- you are saying if I
download the .tar.gz and .zip and extract those two, I will have
precisely the same sources?
Then this fix should be reverted as there is isn't any special
Windows Sources and the official releases should work just fine.There is some difference (timestamps?) which causes building from
the tarred sources to fail on Windows (see bug #69829)."touching" generated files as part of the packaging process is a good
idea for all platforms.Furthermore
extracting the tarred sources with 7zip (which seems to be a pretty
common archiver) results in spurious PaxHeaders.##### directories,
what is bug in 7zip[1], and doesn't really affect the build, but is
confusing nonetheless (and requires more disk space).At least until these issue are solved, IMO it's better to link to
the "Windows" sources packaged as .zip.If there is a need for zip archives I'd put them next to tar.gz etc.
and distribute them via our mirror network.Yep, this could work and were probably proper solution. Except we wouldn't
add some issue for the non Windows users :) I'm not sure, why is it done so
ATM, probably it has its historical reasons. But this would probably cause us
need to update the release process procedure? And, for PHP7 or for any other as
well? Currently that zipball is just generated with the build process, so it'll need
to be sent over somehow. Were anyway doable, wondering what the other
RMs would say. Frankly, I'd leave it as it is - as long as it's reachable and
documented.Thats what we want. We want the official release balls to be generated by an
"official server" using the official toolchain.
There should never be a time when a Release Manager pulls up his notebook,
does a checkout and packages that and uploads. Its bad enough we have this for
pecl exts, but there is no reason for php-src to be playing with fire and
infiltration agencies.That has unfortunately happened before, and resulted in us distributing .orig
files (patch conflicts), .exp, .out, .php, ...
(failed tests results) and even wrongly generated artifacts (due to wrong
bison/re2c versions installed locally).We don't want that happen again.
The official releases should be done on "snap box", and be completely
automated with no room for accidents.
It produces several archives, and we can add .zip to that mix if not already
available.
It's a worthy goal IMHO. Currently it all is done manually as you know.
What! No, I didn't know.
I was describing how the process used to be, and I thought it still was.
Apparently this was dropped in December 2013:
http://git.php.net/?p=php-src.git;a=blobdiff;f=README.RELEASE_PROCESS;h=a0c34f8f7aa5bf8782f394572419167e7ff20c7b;hp=6cc9c4e9ab8fc3102f3fe142b100571362af6742;hb=3eb2b1ac4008acd13f51244c7ba009fa381e79f7;hpb=6f739318fd3dc04a01aec762d449949db481bf5d
I think we need to fix this situation.
Now that you have RMd your first release -- you do seem like the best
person to ask for feedback: What were your pain points? What was the
biggest time waste? What should be improved?
I'm sure we can spin up a server and we script it so all you have to
do is click a button. No accidental personal photos in the release
archives or local malicious tool injecting itself into the archive.
-Hannes
-----Original Message-----
From: Hannes Magnusson [mailto:hannes.magnusson@gmail.com]
Sent: Monday, June 15, 2015 10:29 PM
To: Anatol Belski
Cc: Johannes Schlüter; Christoph Becker; PHP Development; PHP Webmaster ML
Subject: Re: [PHP-DEV] PHP7 releases vs Windows Sources?On Mon, Jun 15, 2015 at 12:51 PM, Anatol Belski anatol.php@belski.net
wrote:Hi Hannes,
-----Original Message-----
From: Hannes Magnusson [mailto:hannes.magnusson@gmail.com]
Sent: Monday, June 15, 2015 8:34 PM
To: Anatol Belski
Cc: Johannes Schlüter; Christoph Becker; PHP Development; PHP
Webmaster ML
Subject: Re: [PHP-DEV] PHP7 releases vs Windows Sources?On Mon, Jun 15, 2015 at 8:38 AM, Anatol Belski anatol.php@belski.net
wrote:Hi Johannes,
-----Original Message-----
From: Johannes Schlüter [mailto:johannes@schlueters.de]
Sent: Monday, June 15, 2015 4:52 PM
To: Christoph Becker
Cc: Hannes Magnusson; Anatol Belski; PHP Development; PHP
Webmaster ML
Subject: Re: [PHP-DEV] PHP7 releases vs Windows Sources?Hannes Magnusson wrote:
Then this fix doesn't make any sense -- you are saying if I
download the .tar.gz and .zip and extract those two, I will
have precisely the same sources?
Then this fix should be reverted as there is isn't any special
Windows Sources and the official releases should work just fine.There is some difference (timestamps?) which causes building
from the tarred sources to fail on Windows (see bug #69829)."touching" generated files as part of the packaging process is a
good idea for all platforms.Furthermore
extracting the tarred sources with 7zip (which seems to be a
pretty common archiver) results in spurious PaxHeaders.#####
directories, what is bug in 7zip[1], and doesn't really affect
the build, but is confusing nonetheless (and requires more disk space).At least until these issue are solved, IMO it's better to link
to the "Windows" sources packaged as .zip.If there is a need for zip archives I'd put them next to tar.gz etc.
and distribute them via our mirror network.Yep, this could work and were probably proper solution. Except we
wouldn't
add some issue for the non Windows users :) I'm not sure, why is it
done so ATM, probably it has its historical reasons. But this would
probably cause us need to update the release process procedure? And,
for PHP7 or for any other as well? Currently that zipball is just
generated with the build process, so it'll need to be sent over
somehow. Were anyway doable, wondering what the other RMs would say.
Frankly, I'd leave it as it is - as long as it's reachable and documented.Thats what we want. We want the official release balls to be
generated by an "official server" using the official toolchain.
There should never be a time when a Release Manager pulls up his
notebook, does a checkout and packages that and uploads. Its bad
enough we have this for pecl exts, but there is no reason for php-src
to be playing with fire and infiltration agencies.That has unfortunately happened before, and resulted in us
distributing .orig files (patch conflicts), .exp, .out, .php, ...
(failed tests results) and even wrongly generated artifacts (due to
wrong bison/re2c versions installed locally).We don't want that happen again.
The official releases should be done on "snap box", and be completely
automated with no room for accidents.
It produces several archives, and we can add .zip to that mix if not
already available.
It's a worthy goal IMHO. Currently it all is done manually as you know.What! No, I didn't know.
I was describing how the process used to be, and I thought it still was.Apparently this was dropped in December 2013:
http://git.php.net/?p=php-
src.git;a=blobdiff;f=README.RELEASE_PROCESS;h=a0c34f8f7aa5bf8782f394572
419167e7ff20c7b;hp=6cc9c4e9ab8fc3102f3fe142b100571362af6742;hb=3eb2b
1ac4008acd13f51244c7ba009fa381e79f7;hpb=6f739318fd3dc04a01aec762d449
949db481bf5dI think we need to fix this situation.
Now that you have RMd your first release -- you do seem like the best person to
ask for feedback: What were your pain points? What was the biggest time
waste? What should be improved?I'm sure we can spin up a server and we script it so all you have to do is click a
button. No accidental personal photos in the release archives or local malicious
tool injecting itself into the archive.
I wasn't yet doing it alone - thanks Ferenc who did many things beforehand, and Kalle managing the php.net news entry and several other things. A learn curve is planned, so until the final any of Kalle or me can do a release completely autonomously. I think a lot more releases need to be done to have a good enough understanding.
However when looking at the README.RELEASE_PROCESS I currently study, there are still many things to do manually, that's what I was talking about. Fe bison/re2c and other tools versions might differ for different release branches. But the most work is probably tracking tickets, NEWS, mails to the lists and all that stuff, packaging itself is not that extreme and is already done by a script. If there was a place that would do release just by one click, it'd simplify it a bit. Of course with before prepared emails, news entries, sources, tools, etc - a risk of making a mistake would decrease, because even one can do a mistake in the mail, but in general on has more time to concentrate on other tasks. I don't think I'm yet ready to define the task, other RMs should also be asked what they think (and that would probably help to understand things deeper, too).
Regards
Anatol
Hi!
It's a worthy goal IMHO. Currently it all is done manually as you know.
What! No, I didn't know.
I was describing how the process used to be, and I thought it still was.
I think making auto-release is a nice idea, but what about signing? I'm
surely not leaving my personal private key on any commonly accessible
server, so how would I sign packages? Except for that, making script
that would do "make release" or "sh scripts/release" and complete the
release cycle (including generating & uploading everything) would be
nice. Right now we have mkdist but it only takes us half-way.
--
Stas Malyshev
smalyshev@gmail.com
Hi!
It's a worthy goal IMHO. Currently it all is done manually as you know.
What! No, I didn't know.
I was describing how the process used to be, and I thought it still was.I think making auto-release is a nice idea, but what about signing? I'm
surely not leaving my personal private key on any commonly accessible
server, so how would I sign packages? Except for that, making script
that would do "make release" or "sh scripts/release" and complete the
release cycle (including generating & uploading everything) would be
nice. Right now we have mkdist but it only takes us half-way.
gpg-agent forwarding over ssh?
- Goto https://release.php.net/
- Login with your master credentials (only allows logins for whitelisted users).
- White page suggest you are creating x.y.z+1 release from branch x_y
- If yes; press "MAKE MAGIC"
- If no; write the version number in input field, select branch from combobox
- Press; "I KNOW WHAT IM DOING"
This will trigger generating all files needed, bumping version and
whatever. Tags. Creates archives. All that good stuff.
"5 minutes later" you get email; "release is ready!" with links to the archives
You fetch them, explore the archives, run the tests and you the things
we all know we should do but don't :)
Then:
ssh -R ~username/.gnupg/S.gpg-agent -o "StreamLocalBindUnlink=yes"
release.php.net '/usr/local/bin/confirm x.y.z+1'
It'll sign the git tag (using your forwarded agent), push upstream,
push archives to php-distribution.git
Then. In the next release of the tool:
- The whitepage extracts the NEWS entries and does the html/php
formatting for phpweb - Gives you checkboxes to choose pick the highlights
- The highlights will be used for the standard phpweb news xml.
.... - Profit
-Hannes
Hi!
gpg-agent forwarding over ssh?
Well, if that works then fine. I never tried it (actually didn't use the
agent that much at all) but why not.
- Goto https://release.php.net/
- Login with your master credentials (only allows logins for whitelisted users).
- White page suggest you are creating x.y.z+1 release from branch x_y
- If yes; press "MAKE MAGIC"
- If no; write the version number in input field, select branch from combobox
- Press; "I KNOW WHAT IM DOING"
Looks good so far, except that I'd probably feel better doing the tag
manually. First because it can be moved around (forgot to update news,
last minute patch, made typo somewhere, added CVE, etc.), second again
because it's signed and I kind of feel more confident knowing I (or
other RM) is the guy who actually personally created that tag. It's not
a very important point, just a preference, at least for me. If other RMs
feel different then fine with it as is.
ssh -R ~username/.gnupg/S.gpg-agent -o "StreamLocalBindUnlink=yes"
release.php.net '/usr/local/bin/confirm x.y.z+1'It'll sign the git tag (using your forwarded agent), push upstream,
push archives to php-distribution.git
We need to sign the packages, not only tags. Creating tag is actually
not that big a deal manually, it's one git command. Packaging from it is
more involved. But if the agent works, yes, we can do it with scripts,
that's fine.
Then. In the next release of the tool:
- The whitepage extracts the NEWS entries and does the html/php
formatting for phpweb- Gives you checkboxes to choose pick the highlights
- The highlights will be used for the standard phpweb news xml.
....- Profit
I'm all for it. I know my RMship for 5.4 is will be done soon, so my
personal profit from it would be pretty low, but for the sake of next
RMs automating the dozen of manual tasks one has to do to roll the
release would be a nice thing. We just need to be careful with phpweb,
etc. patching given that we can have 3 branches being released in
parallel, sometime conflicts happen.
--
Stas Malyshev
smalyshev@gmail.com
On Jun 16, 2015 1:34 AM, "Hannes Magnusson" .
Thats what we want. We want the official release balls to be generated
by an "official server" using the official toolchain.
For the tarballs? Yes. Only that it does not happen last time I checked.
There should never be a time when a Release Manager pulls up his
notebook, does a checkout and packages that and uploads. Its bad
enough we have this for pecl exts, but there is no reason for php-src
to be playing with fire and infiltration agencies.
It was the goals of snaps, but given the issues we have to keep it up,
running and accessible, it does not happen.
As of "infiltration agencies", code signing helps. Using https (htts)
helps. But you did not want it.
That has unfortunately happened before, and resulted in us
distributing .orig files (patch conflicts), .exp, .out, .php, ...
(failed tests results) and even wrongly generated artifacts (due to
wrong bison/re2c versions installed locally).
Yes, we really need a standard box for that (snaps?).
We don't want that happen again.
The official releases should be done on "snap box", and be completely
automated with no room for accidents.
It produces several archives, and we can add .zip to that mix if not
already available.It should be obvious that any binary distribution that aims to be
official PHP.net release should use this official release, not some
custom mix of things.
It is important that these official binaries also don't regenerate the
files in the archive.
If there is an extra file (.w32?), or touching of files, required to
make this archive usable to generate binaries from - then please fix
the root problem; touch the file before the packaging (and update the
README :)).
The sources zip archives have no code difference. They are a convenient
archive used by many builds tools. That did not change since the last time
we discussed that.
-Hannes
--
PHP Webmaster List Mailing List (http://www.php.net/)
Johannes Schlüter wrote:
There is some difference (timestamps?) which causes building from the
tarred sources to fail on Windows (see bug #69829)."touching" generated files as part of the packaging process is a good
idea for all platforms.
The files generated from zend_language_parser.y are newer than the
ZLP.y, and that caused the build to fail on my machine. After touching
ZLP.y it worked.
I had a closer look at the issue and found the problem is caused by
zend_parse being defined as ZEND_API in zend_globals_macros.h, but as
"normal" function in zend_language_parser.h/c. Fixing this
provisionally let the build succeed, and also removing the declarations
seems to work fine.
--
Christoph M. Becker
Yeah, it makes sense, just if you look into the bug #69829 . It was extracted from the tarball packaged on Linux, and it went wrong. Also I've just found the same issue reported with drupal - https://groups.drupal.org/node/315878 PaxHeaders and all that. We probably don't want to receive more such bug tickets and spend time on them, so more clarification will only do a good job.
More info so people just use compatible package which extracts out of the box (eq zip can be opened just with the normal explorer). Btw I just got the same when I use 7-zip on Windows with our official tarball, even the older one.
Regards
Anatol
-----Original Message-----
From: Hannes Magnusson [mailto:hannes.magnusson@gmail.com]
Sent: Monday, June 15, 2015 4:08 PM
To: Anatol Belski
Cc: Anatol Belski; PHP Development; PHP Webmaster ML
Subject: Re: [PHP-DEV] PHP7 releases vs Windows Sources?Then this fix doesn't make any sense -- you are saying if I download
the .tar.gz and .zip and extract those two, I will have precisely the
same sources?
Then this fix should be reverted as there is isn't any special Windows
Sources and the official releases should work just fine.-Hannes
Hi Hannes,
Nope, it's the same source and the same tag is always used. The tag is the
actual reference for any release. But usually people on Windows don't have
things like tar,gz and others. Even if they have - the compatibility might be just
bad. So it's zipped.Regards
Anatol
-----Original Message-----
From: Hannes Magnusson [mailto:hannes.magnusson@gmail.com]
Sent: Monday, June 15, 2015 3:52 PM
To: Anatol Belski; PHP Development
Cc: PHP Webmaster ML
Subject: [PHP-DEV] PHP7 releases vs Windows Sources?What is the difference between "Windows Sources" and our official releases?
Did windows.php.net fork php or something? Embedded other things?
Are the binaries really not generated from the official sources?
This sounds like a horrible idea if true.-Hannes
Commit: 9883c8f0bbcb64ad42ce66d694fffd848fc2ebcc
Author: Anatol Belski ab@php.net Mon, 15 Jun 2015 14:39:31
+0200
Parents: d7f7d44e25c4bb43de7696db47189026428daaac
Branches: masterLink:
http://git.php.net/?p=web/php.git;a=commitdiff;h=9883c8f0bbcb64ad42ce66d6
94fffd848fc2ebcc
Log:
apply patch from bug #69829And, we probably should keep this wording in the next announcement
Bugs:
https://bugs.php.net/69829Changed paths:
M archive/entries/2015-06-11-3.xmlDiff:
diff --git a/archive/entries/2015-06-11-3.xml
b/archive/entries/2015-06-11-3.xml
index 232dcee..be5d386 100644
--- a/archive/entries/2015-06-11-3.xml
+++ b/archive/entries/2015-06-11-3.xml
@@ -43,7 +43,7 @@<p> For source downloads of PHP 7.0.0 Alpha 1 please visit
the <a href="https://downloads.php.net/ab/">download page</a>,Windows binaries
the <a href="https://downloads.php.net/ab/">download page</a>,- Windows sources and binaries
can be found on <a href="http://windows.php.net/qa/">windows.php.net/qa/</a>;.
</p>--
PHP Webmaster List Mailing List (http://www.php.net/) To unsubscribe,
visit: http://www.php.net/unsub.php--
To unsubscribe, visit:
http://www.php.net/unsub.php
Hi!
Then this fix doesn't make any sense -- you are saying if I download
the .tar.gz and .zip and extract those two, I will have precisely the
same sources?
Should be the same sources. We shouldn't distribute anything that isn't
under the respective tag as official sources, so I assume they are.
Making them part of the distro may not be a bad idea too, this way they
can be signed. Of course, signing one more file is 33 to 50% more work,
but I think RMs can deal with it.
--
Stas Malyshev
smalyshev@gmail.com
On Tue, Jun 16, 2015 at 12:42 AM, Stanislav Malyshev smalyshev@gmail.com
wrote:
Hi!
Then this fix doesn't make any sense -- you are saying if I download
the .tar.gz and .zip and extract those two, I will have precisely the
same sources?Should be the same sources. We shouldn't distribute anything that isn't
under the respective tag as official sources, so I assume they are.
Making them part of the distro may not be a bad idea too, this way they
can be signed. Of course, signing one more file is 33 to 50% more work,
but I think RMs can deal with it.
about signing, recently I got a question that somebody couldn't verify the
tarball signature, because he was trying to verify the extracted contents
instead of the compressed file.
he was trying to do that, because that is how the kernel.org releases are
signed:
https://www.kernel.org/signature.html#using-gnupg-to-verify-kernel-signatures
and they do that because that way you only need one signature for a given
release regardless of the number of compression formats you provide.
maybe this is something what we should consider also.
--
Ferenc Kovács
@Tyr43l - http://tyrael.hu
Hi!
about signing, recently I got a question that somebody couldn't verify
the tarball signature, because he was trying to verify the extracted
contents instead of the compressed file.
he was trying to do that, because that is how the kernel.org
http://kernel.org releases are signed:
https://www.kernel.org/signature.html#using-gnupg-to-verify-kernel-signatures
I far as I understood, this one verifies .tar - i.e. uncompressed, but
not extracted. Am I wrong? If that's right, then it doesn't solve the
issue with .zip.
--
Stas Malyshev
smalyshev@gmail.com
On Wed, Jun 17, 2015 at 3:19 AM, Stanislav Malyshev smalyshev@gmail.com
wrote:
Hi!
about signing, recently I got a question that somebody couldn't verify
the tarball signature, because he was trying to verify the extracted
contents instead of the compressed file.
he was trying to do that, because that is how the kernel.org
http://kernel.org releases are signed:https://www.kernel.org/signature.html#using-gnupg-to-verify-kernel-signatures
I far as I understood, this one verifies .tar - i.e. uncompressed, but
not extracted. Am I wrong? If that's right, then it doesn't solve the
issue with .zip.--
Stas Malyshev
smalyshev@gmail.com
yep, that doesn't solves the separate signing of zips, buth one signature
would be enough for all tar.* files
--
Ferenc Kovács
@Tyr43l - http://tyrael.hu
I thought the files generated by genfiles for the linux tarballs are
different in the windows zips.
On Mon, Jun 15, 2015 at 4:02 PM, Anatol Belski anatol.php@belski.net
wrote:
Hi Hannes,
Nope, it's the same source and the same tag is always used. The tag is the
actual reference for any release. But usually people on Windows don't have
things like tar,gz and others. Even if they have - the compatibility might
be just bad. So it's zipped.Regards
Anatol
-----Original Message-----
From: Hannes Magnusson [mailto:hannes.magnusson@gmail.com]
Sent: Monday, June 15, 2015 3:52 PM
To: Anatol Belski; PHP Development
Cc: PHP Webmaster ML
Subject: [PHP-DEV] PHP7 releases vs Windows Sources?What is the difference between "Windows Sources" and our official
releases?Did windows.php.net fork php or something? Embedded other things?
Are the binaries really not generated from the official sources?
This sounds like a horrible idea if true.-Hannes
Commit: 9883c8f0bbcb64ad42ce66d694fffd848fc2ebcc
Author: Anatol Belski ab@php.net Mon, 15 Jun 2015
14:39:31 +0200
Parents: d7f7d44e25c4bb43de7696db47189026428daaac
Branches: masterLink:
http://git.php.net/?p=web/php.git;a=commitdiff;h=9883c8f0bbcb64ad42ce66d6
94fffd848fc2ebcc
Log:
apply patch from bug #69829And, we probably should keep this wording in the next announcement
Bugs:
https://bugs.php.net/69829Changed paths:
M archive/entries/2015-06-11-3.xmlDiff:
diff --git a/archive/entries/2015-06-11-3.xml
b/archive/entries/2015-06-11-3.xml
index 232dcee..be5d386 100644
--- a/archive/entries/2015-06-11-3.xml
+++ b/archive/entries/2015-06-11-3.xml
@@ -43,7 +43,7 @@<p> For source downloads of PHP 7.0.0 Alpha 1 please visit
the <a href="https://downloads.php.net/ab/">download page</a>,Windows binaries
the <a href="https://downloads.php.net/ab/">download page</a>,- Windows sources and binaries
can be found on <a href="http://windows.php.net/qa/">windows.php.net/qa/</a>;.
</p>--
PHP Webmaster List Mailing List (http://www.php.net/) To unsubscribe,
visit: http://www.php.net/unsub.php--
To unsubscribe,
visit:
http://www.php.net/unsub.php--
--
Ferenc Kovács
@Tyr43l - http://tyrael.hu
Yep, the generated files in Windows are just the same as in the tag. But what I’m talking about the package format itself. As the difference in the generated files doesn’t mean something changed in the release itself.
Regards
Anatol
From: Ferenc Kovacs [mailto:tyra3l@gmail.com]
Sent: Monday, June 15, 2015 4:23 PM
To: Anatol Belski
Cc: Hannes Magnusson; Anatol Belski; PHP Development; PHP Webmaster ML
Subject: Re: [PHP-DEV] PHP7 releases vs Windows Sources?
I thought the files generated by genfiles for the linux tarballs are different in the windows zips.
Hi Hannes,
Nope, it's the same source and the same tag is always used. The tag is the actual reference for any release. But usually people on Windows don't have things like tar,gz and others. Even if they have - the compatibility might be just bad. So it's zipped.
Regards
Anatol
-----Original Message-----
From: Hannes Magnusson [mailto:hannes.magnusson@gmail.com mailto:hannes.magnusson@gmail.com ]
Sent: Monday, June 15, 2015 3:52 PM
To: Anatol Belski; PHP Development
Cc: PHP Webmaster ML
Subject: [PHP-DEV] PHP7 releases vs Windows Sources?What is the difference between "Windows Sources" and our official releases?
Did windows.php.net http://windows.php.net fork php or something? Embedded other things?
Are the binaries really not generated from the official sources?
This sounds like a horrible idea if true.-Hannes
Commit: 9883c8f0bbcb64ad42ce66d694fffd848fc2ebcc
Author: Anatol Belski <ab@php.net mailto:ab@php.net > Mon, 15 Jun 2015 14:39:31 +0200
Parents: d7f7d44e25c4bb43de7696db47189026428daaac
Branches: masterLink:
http://git.php.net/?p=web/php.git;a=commitdiff;h=9883c8f0bbcb64ad42ce66d6
94fffd848fc2ebccLog:
apply patch from bug #69829And, we probably should keep this wording in the next announcement
Bugs:
https://bugs.php.net/69829Changed paths:
M archive/entries/2015-06-11-3.xmlDiff:
diff --git a/archive/entries/2015-06-11-3.xml
b/archive/entries/2015-06-11-3.xml
index 232dcee..be5d386 100644
--- a/archive/entries/2015-06-11-3.xml
+++ b/archive/entries/2015-06-11-3.xml
@@ -43,7 +43,7 @@<p> For source downloads of PHP 7.0.0 Alpha 1 please visit
the <a href="https://downloads.php.net/ab/">download page</a>,Windows binaries
the <a href="https://downloads.php.net/ab/">download page</a>,- Windows sources and binaries
can be found on <a href="http://windows.php.net/qa/">windows.php.net/qa/ http://windows.php.net/qa/ </a>.
</p>--
PHP Webmaster List Mailing List (http://www.php.net/) To unsubscribe,
visit: http://www.php.net/unsub.php--
To unsubscribe, visit:
http://www.php.net/unsub.php
--
--
Ferenc Kovács
@Tyr43l - http://tyrael.hu