Newsgroups: php.internals,php.webmaster
Path: news.php.net
Xref: news.php.net php.internals:86669 php.webmaster:21354
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.217.177 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <012e01d0a781$4f4a17e0$edde47a0$@belski.net>
References: <CADNQb0VcfzJ7U+_2t99vxpdXRSEAeHG98eAdMDB+9EOF0=rAXg@mail.gmail.com>
	<00c501d0a773$f84fee90$e8efcbb0$@belski.net>
	<CADNQb0WOx8mcrmBdofrZ4CqMJHJrdmb6oQnJTQqxmrHYLq5Xqw@mail.gmail.com>
	<557EDF48.9000800@gmx.de>
	<1434379932.17693.5.camel@kuechenschabe>
	<012e01d0a781$4f4a17e0$edde47a0$@belski.net>
Date: Mon, 15 Jun 2015 11:34:00 -0700
Message-ID: <CADNQb0WrZ5nAFjNKi6935pd-JabiWTQzs56G_Q1QaEzL3rV9iw@mail.gmail.com>
To: Anatol Belski <anatol.php@belski.net>
Cc: =?UTF-8?Q?Johannes_Schl=C3=BCter?= <johannes@schlueters.de>, 
	Christoph Becker <cmbecker69@gmx.de>, PHP Development <internals@lists.php.net>, 
	PHP Webmaster ML <php-webmaster@lists.php.net>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PHP-DEV] PHP7 releases vs Windows Sources?
From: hannes.magnusson@gmail.com (Hannes Magnusson)

On Mon, Jun 15, 2015 at 8:38 AM, Anatol Belski <anatol.php@belski.net> wrot=
e:
> Hi Johannes,
>
>> -----Original Message-----
>> From: Johannes Schl=C3=BCter [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?
>>
>> On Mon, 2015-06-15 at 16:20 +0200, Christoph Becker wrote:
>> > 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 id=
ea 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 cau=
se us need to update the release process procedure? And, for PHP7 or for an=
y other as well? Currently that zipball is just generated with the build pr=
ocess, so it'll need to be sent over somehow. Were anyway doable,  wonderin=
g 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