Newsgroups: php.internals,php.webmaster
Path: news.php.net
Xref: news.php.net php.internals:86680 php.webmaster:21358
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>	<018b01d0a7a4$b572f730$2058e590$@belski.net> <CADNQb0WkXH-M0Yc5gD6+-=x4YEzMD0eNNwuo3u1=ghpz5i=ENw@mail.gmail.com>
In-Reply-To: <CADNQb0WkXH-M0Yc5gD6+-=x4YEzMD0eNNwuo3u1=ghpz5i=ENw@mail.gmail.com>
Date: Mon, 15 Jun 2015 22:52:05 +0200
Message-ID: <01c301d0a7ad$25a956e0$70fc04a0$@belski.net>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Thread-Index: AQHpdUQkhoANRXvSxO0Sr7gX+wtPhgKluB3LAVkrseQCKPEE+AGd8A9RAjwogR4CvFJoigF/pxvEAXCer8uc/vbdkA==
Content-Language: en-us
Subject: RE: [PHP-DEV] PHP7 releases vs Windows Sources?
From: anatol.php@belski.net ("Anatol Belski")



> -----Original Message-----
> From: Hannes Magnusson [mailto:hannes.magnusson@gmail.com]
> Sent: Monday, June 15, 2015 10:29 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 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=C3=BCter; 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=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.
> >> >
> >>
> >>
> >>
> >> 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.
>=20
>=20
> What! No, I didn't know.
> I was describing how the process used to be, and I thought it still =
was.
>=20
> Apparently this was dropped in December 2013:
> http://git.php.net/?p=3Dphp-
> =
src.git;a=3Dblobdiff;f=3DREADME.RELEASE_PROCESS;h=3Da0c34f8f7aa5bf8782f39=
4572
> =
419167e7ff20c7b;hp=3D6cc9c4e9ab8fc3102f3fe142b100571362af6742;hb=3D3eb2b
> 1ac4008acd13f51244c7ba009fa381e79f7;hpb=3D6f739318fd3dc04a01aec762d449
> 949db481bf5d
>=20
>=20
> I think we need to fix this situation.
>=20
> 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?
>=20
> 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.
>=20
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