[PHP-WEBMASTER] Re: [PHP-DEV] Re: [PHP-WEBMASTER] RE: [PHP-DEV] PHP7 releases vs Windows Sources?
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 -- PHP Webmaster List Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-WEBMASTER] Re: [PHP-DEV] Re: [PHP-WEBMASTER] RE: [PHP-DEV] PHP7 releases vs Windows Sources?
On Wed, Jun 17, 2015 at 12:17 AM, Johannes Schlüter wrote: > On Mon, 2015-06-15 at 22:45 +0700, Pierre Joye 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 -- PHP Webmaster List Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-WEBMASTER] Re: [PHP-DEV] Re: [PHP-WEBMASTER] RE: [PHP-DEV] PHP7 releases vs Windows Sources?
On Mon, 2015-06-15 at 22:45 +0700, Pierre Joye 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. johannes signature.asc Description: This is a digitally signed message part
Re: [PHP-WEBMASTER] Re: [PHP-DEV] PHP7 releases vs Windows Sources?
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/) > To unsubscribe, visit: http://www.php.net/unsub.php >
Re: [PHP-WEBMASTER] RE: [PHP-DEV] PHP7 releases vs Windows Sources?
On Jun 15, 2015 10:38 PM, "Anatol Belski" wrote: > > Hi Johannes, > > > -Original Message- > > From: Johannes Schlüter [mailto:johan...@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. 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
