Newsgroups: php.internals,php.webmaster
Path: news.php.net
Xref: news.php.net php.internals:86671 php.webmaster:21355
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain belski.net from 85.214.73.107 cause and error)
To: "'Hannes Magnusson'" <hannes.magnusson@gmail.com>
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>
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> <CADNQb0WrZ5nAFjNKi6935pd-JabiWTQzs56G_Q1QaEzL3rV9iw@mail.gmail.com>
In-Reply-To: <CADNQb0WrZ5nAFjNKi6935pd-JabiWTQzs56G_Q1QaEzL3rV9iw@mail.gmail.com>
Date: Mon, 15 Jun 2015 21:51:41 +0200
Message-ID: <018b01d0a7a4$b572f730$2058e590$@belski.net>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Thread-Index: AQHpdUQkhoANRXvSxO0Sr7gX+wtPhgKluB3LAVkrseQCKPEE+AGd8A9RAjwogR4CvFJoip0WZhHw
Content-Language: en-us
Subject: RE: [PHP-DEV] PHP7 releases vs Windows Sources?
From: anatol.php@belski.net ("Anatol Belski")

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=C3=BCter; Christoph Becker; PHP Development; PHP =
Webmaster ML
> Subject: Re: [PHP-DEV] PHP7 releases vs Windows Sources?
>=20
> On Mon, Jun 15, 2015 at 8:38 AM, Anatol Belski <anatol.php@belski.net> =
wrote:
> > 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
> >> 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.
> >
>=20
>=20
>=20
> 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.
>=20
> 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).
>=20
> 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.=20

> 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.=20

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=20