> -----Original Message----- > From: Hannes Magnusson [mailto:hannes.magnus...@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....@belski.net> > wrote: > > Hi Hannes, > > > >> -----Original Message----- > >> From: Hannes Magnusson [mailto:hannes.magnus...@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....@belski.net> > 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. > >> > > >> > >> > >> > >> 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 > 949db481bf5d > > > 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. > 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 -- PHP Webmaster List Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
