# post 5.3.0 development - Thread: https://externals.io/message/44467 - Original archive: https://news-web.php.net/php.internals/44467 - Started by Lukas Kahwe Smith on 2009-06-26T15:26:47+00:00 - Messages: 28 - Page 1 of 2: messages 1 to 25 (25 per page, add `?page=N` to the URL) - Next page: https://externals.io/message/44467.md?page=2 - Reply by email to internals@lists.php.net - More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt --- ## #44467 — Lukas Kahwe Smith — 2009-06-26T15:26:47+00:00 URL: https://externals.io/message/44467#44467 Aloha, So the last fix is just being prepared for a commit and so we will be tagging 5.3.0 soon. We would like to up hold the commit freeze until 5.3.0 is announced next Tuesday. After this period bug fixes can be applied again. However feature additions should wait until after 5.3.1, which we expect to be released within a month or two. As always if you are unsure, ask Johannes. And also as always if there is a solid reason, common sense rules, but please do ask first. regards, Johannes and Lukas --- ## #44470 — Scott MacVicar — 2009-06-26T17:30:54+00:00 URL: https://externals.io/message/44467#44470 · In reply to: #44467 > Aloha, > > So the last fix is just being prepared for a commit and so we will > be tagging 5.3.0 soon. > > We would like to up hold the commit freeze until 5.3.0 is announced > next Tuesday. > This freeze that you guys have implemented is frustrating, just branch 5_3 into a release branch and Johannes can take selective fixes from 5_3 as needed. We all know your reasons for the freeze and agree with it but holding up regular development is a PITA. Scott --- ## #44471 — Ilia Alshanetsky — 2009-06-26T17:39:33+00:00 URL: https://externals.io/message/44467#44471 · In reply to: #44470 > > > > […] > > This freeze that you guys have implemented is frustrating, just > branch 5_3 into a release branch and Johannes can take selective > fixes from 5_3 as needed. +1 A long term freeze will simply mean that some bug fixes will be missed in the 5.3 release and we'd end up with a less stable version in the long term. I know it makes release cycle that much simpler, but lets make sure we don't stall the development. --- ## #44472 — Hannes Magnusson — 2009-06-26T18:22:09+00:00 URL: https://externals.io/message/44467#44472 · In reply to: #44467 > We would like to up hold the commit freeze until 5.3.0 is announced next > Tuesday. And the move to SVN? It'll require a complete cvs.php.net freeze for couple of days, I think? -Hannes --- ## #44473 — Gwynne Raskind — 2009-06-26T18:26:23+00:00 URL: https://externals.io/message/44467#44473 · In reply to: #44472 > > […] > And the move to SVN? It'll require a complete cvs.php.net freeze for > couple of days, I think? Yes, but it's not ready for that yet; an unfreeze after 5.3's release won't kill anyway. But keep in mind that the SVN freeze will freeze PEAR and PECL and GTK and... well, everyone. Once CVS write access is shut off, it'll never be turned back on (unless there's a problem with SVN). Whereas this freeze is just on PHP itself. -- Gwynne --- ## #44474 — Pierre Joye — 2009-06-26T18:26:47+00:00 URL: https://externals.io/message/44467#44474 · In reply to: #44470 > > > > […] > > This freeze that you guys have implemented is frustrating, just branch 5_3 > into a release branch and Johannes can take selective fixes from 5_3 as > needed. > > We all know your reasons for the freeze and agree with it but holding up > regular development is a PITA. It is not holding up development. It is about getting a viable release cycle and to give us the minimum safety to release 5.3.1 in a reasonable time frame. Please explain me what's wrong to allow only bug fixes for this phase? Also please note that we have HEAD for all the developments and new features. Cheers, -- Pierre http://blog.thepimp.net | http://www.libgd.org --- ## #44478 — Lukas Kahwe Smith — 2009-06-26T18:59:14+00:00 URL: https://externals.io/message/44467#44478 · In reply to: #44474 > On Fri, Jun 26, 2009 at 7:30 PM, Scott MacVicar > wrote: > > […] > > It is not holding up development. It is about getting a viable release > cycle and to give us the minimum safety to release 5.3.1 in a > reasonable time frame. Please explain me what's wrong to allow only > bug fixes for this phase? > > Also please note that we have HEAD for all the developments and new > features. Exactly. I will do my best to track things that need to be merged. Best is to note if something needs to be merged. But if you all feel it's such a huge burden then you can of course insist on putting the burden on the RMs. The fact of the matter is that our current infrastructure is not fit for providing both sides with an efficient solution. Regards, Lukas --- ## #44479 — Rasmus Lerdorf — 2009-06-26T19:11:38+00:00 URL: https://externals.io/message/44467#44479 · In reply to: #44478 Lukas Kahwe Smith wrote: > Exactly. > I will do my best to track things that need to be merged. Best is to > note if something needs to be merged. > > But if you all feel it's such a huge burden then you can of course > insist on putting the burden on the RMs. The fact of the matter is that > our current infrastructure is not fit for providing both sides with an > efficient solution. Keep an eye on http://bugs.php.net/48518 I don't think we can let 5.3 out the door with this regression. -Rasmus --- ## #44481 — Pierre Joye — 2009-06-26T19:18:01+00:00 URL: https://externals.io/message/44467#44481 · In reply to: #44479 > Lukas Kahwe Smith wrote: > > […] > > Keep an eye on http://bugs.php.net/48518 > > I don't think we can let 5.3 out the door with this regression. btw, 5.2.10 is out too with this regression. If I'm not mistaken. Cheers, -- Pierre http://blog.thepimp.net | http://www.libgd.org --- ## #44482 — Rasmus Lerdorf — 2009-06-26T19:26:06+00:00 URL: https://externals.io/message/44467#44482 · In reply to: #44481 Pierre Joye wrote: > > > […] > > btw, 5.2.10 is out too with this regression. If I'm not mistaken. It is, and it is causing some nasty headaches because it is non-trivial to debug. -Rasmus --- ## #44483 — Scott MacVicar — 2009-06-26T19:26:48+00:00 URL: https://externals.io/message/44467#44483 · In reply to: #44478 > > > > […] > > Exactly. > I will do my best to track things that need to be merged. Best is to > note if something needs to be merged. > > But if you all feel it's such a huge burden then you can of course > insist on putting the burden on the RMs. The fact of the matter is > that our current infrastructure is not fit for providing both sides > with an efficient solution. > If we're freezing some more after this release for the SVN conversion then we could have a pretty cold branch for another week or so. As I've already said, I agree with only allow verified bug fixes by Johannes into 5.3.0. it's this extra bureaucracy that is getting added on top that's sucking hard. I don't want to leave it up to someone else to merge it into 5.3, I should be doing it myself. It's possible that things could get accidentally missed wen someone else is applying it. Scott --- ## #44486 — Greg Beaver — 2009-06-26T19:46:44+00:00 URL: https://externals.io/message/44467#44486 · In reply to: #44483 Scott MacVicar wrote: > If we're freezing some more after this release for the SVN conversion > then we could have a pretty cold branch for another week or so. > > As I've already said, I agree with only allow verified bug fixes by > Johannes into 5.3.0. it's this extra bureaucracy that is getting added > on top that's sucking hard. > > I don't want to leave it up to someone else to merge it into 5.3, I > should be doing it myself. It's possible that things could get > accidentally missed wen someone else is applying it. I completely agree, which is why the solution is: 1) commit to HEAD 2) send a message to internals CC lukas with a link to the commit message 3) after the freeze is over, Lukas forwards your message back to you, and you do the merge. Greg --- ## #44487 — Pierre Joye — 2009-06-26T20:12:27+00:00 URL: https://externals.io/message/44467#44487 · In reply to: #44483 you totally misunderstood the mail. The freeze is about the days between now and the release itself on Tuesday (monday evening actually). That's perfectly valid. The idea then is to allow only bug fixes in 5.3.1, and only bug fixes. What's wrong with that? -- Pierre > > > […] > > If we're freezing some more after this release for the SVN conversion then > we could have a pretty cold branch for another week or so. > > As I've already said, I agree with only allow verified bug fixes by Johannes > into 5.3.0. it's this extra bureaucracy that is getting added on top that's > sucking hard. > > I don't want to leave it up to someone else to merge it into 5.3, I should > be doing it myself. It's possible that things could get accidentally missed > wen someone else is applying it. > > Scott > -- Pierre http://blog.thepimp.net | http://www.libgd.org --- ## #44488 — Scott MacVicar — 2009-06-26T20:35:58+00:00 URL: https://externals.io/message/44467#44488 · In reply to: #44487 I *completely* agree with making sure 5.3.0 is stable and stopping extra things sneaking their way in. I just don't like the way that it is being done. If the release is tagged and built, then why continue with the freeze? Why not open it up for bug fixes towards 5.3.1? If the reason that you're about to be given is, we might find something critical and need to re-roll 5.3.0 then branch from the tag you've created, fix what's needed and re-tag. Even though CVS sucks it does allow this. This is the way the Mozilla project has done it for years, following their example we'd just create a PHP_5_3_RELBRANCH and work from that. The RMs are the only ones that get to decide what goes in after the freeze. https://wiki.mozilla.org/SeaMonkey:Release_Process Scott > you totally misunderstood the mail. The freeze is about the days > between now and the release itself on Tuesday (monday evening > actually). That's perfectly valid. > > The idea then is to allow only bug fixes in 5.3.1, and only bug fixes. > What's wrong with that? > > -- > Pierre > > > > > On Fri, Jun 26, 2009 at 9:26 PM, Scott MacVicar > wrote: > > […] --- ## #44489 — Pierre Joye — 2009-06-26T20:47:09+00:00 URL: https://externals.io/message/44467#44489 · In reply to: #44488 this process is known and we already said that we have to change the way we do it after 5.3.0. > I *completely* agree with making sure 5.3.0 is stable and stopping extra > things sneaking their way in. I just don't like the way that it is being > done. > > If the release is tagged and built, then why continue with the freeze? Why > not open it up for bug fixes towards 5.3.1? > > If the reason that you're about to be given is, we might find something > critical and need to re-roll 5.3.0 then branch from the tag you've created, > fix what's needed and re-tag. Even though CVS sucks it does allow this. > > This is the way the Mozilla project has done it for years, following their > example we'd just create a PHP_5_3_RELBRANCH and work from that. The RMs are > the only ones that get to decide what goes in after the freeze. > > https://wiki.mozilla.org/SeaMonkey:Release_Process > > Scott > > > > > > […] > -- Pierre http://blog.thepimp.net | http://www.libgd.org --- ## #44490 — Hannes Magnusson — 2009-06-26T20:47:53+00:00 URL: https://externals.io/message/44467#44490 · In reply to: #44488 > If the reason that you're about to be given is, we might find something > critical and need to re-roll 5.3.0 then branch from the tag you've created, > fix what's needed and re-tag. Even though CVS sucks it does allow this. Fair enough. However. You should still be committing to HEAD before 5_whatever. And we are about to switch from SVN. Lets keep the release model as-is for 3more days, migrate to SVN and then design a better release model. -Hannes p.s. I missed the tagging by an hour, so I feel your frustration - but you should be developing in the developer branch, not release branch... --- ## #44497 — Rasmus Lerdorf — 2009-06-26T22:02:43+00:00 URL: https://externals.io/message/44467#44497 · In reply to: #44481 Pierre Joye wrote: > > > […] > > btw, 5.2.10 is out too with this regression. If I'm not mistaken. Ok, I am running out of time for this one today. As Tony mentioned in his original bug report for 48518: Simple patch fixes this problem, but there is another one to consider: should the refcount be decreased when closing the cURL handle? That would be a yes. I don't see an easy way to relate an open File-Handle resource back to the curl handle though short of walking all open file handles and checking them against the fps in the curl struct, or creating a separate llist for these resources tied to the curl handle. If someone has an idea for a clean fix here, please speak up. Second, because there was no addref on the fp before, a simple curl_exec($ch); fclose($fp); would force a flush and the data would be available in the file. Even if we decrement the refcount on the file handle resource in the curl handle destructor, that still doesn't bring us back to that behaviour because the fclose there doesn't actually close the file yet, as it shouldn't. So here, a secondary fix, and a side-effect of this issue, is that we should probably force a flush on the fclose for any flushable streams we try to close when there are outstanding references holding them open. I think doing both of these should take care of this one. And 10 years ago I'd be hacking on this for the next 3 hours, but right now I am spending the next 3 hours picking up Carl from Lego Camp and taking him to his piano lesson... -Rasmus --- ## #44503 — Ilia Alshanetsky — 2009-06-26T23:52:51+00:00 URL: https://externals.io/message/44467#44503 · In reply to: #44497 Here is the least intrusive fix I can come up for this bug. When doing `curl_close()` the dtor will force flush of data on a file stream synching the data to disk. As far as I can tell (using Rasmus' example) this appears to adequately fix the problem and I see no immediate side-effects. --- ## #44504 — Scott MacVicar — 2009-06-26T23:55:00+00:00 URL: https://externals.io/message/44467#44504 · In reply to: #44503 You have an assignment instead of a comparison there. Scott > Just to keep the list in synch with the irc discussion. I pointed out > that this is only half of the fix. The refcount still prevents fclose > from flushing the data, so if you do: > > $url = 'http://slowgeek.com/test.xml'; > $cfile = 'out.xml'; > $ch = curl_init($url); > curl_setopt($ch, CURLOPT_FILE, $fp = fopen($cfile,'w')); > $status = curl_exec($ch); > fclose($fp); > $data = file_get_contents($cfile); > var_dump($data); // 0 bytes here > curl_close($ch); > $data = file_get_contents($cfile); > var_dump($data); // full contents here > > I still think we need to look at doing a flush on an fclose which > doesn't reach the stream destructor due to refcount issues. > > Can anybody think of any side-effects of a flush on a stream close? > > -Rasmus --- ## #44509 — Rasmus Lerdorf — 2009-06-27T00:44:21+00:00 URL: https://externals.io/message/44467#44509 · In reply to: #44507 Ilia Alshanetsky wrote: > After some conversations with Rasmus on IRC i've come up with the > following patch: > > http://ilia.ws/patch/curl.txt > > This basically forces `flush()` on the header & output streams right after > `curl_exec()`, this ensures that the data retrieved by curl is synched to > disk. The patch is also self contained to curl so no external elements > are affected by the patch. This looks good to me. It means 5.2.9 code will keep working. The only slight behavioural change where the fp is now flushed before the fclose/curl_close, but if anybody relied on a read at that point not returning the last buffer, they deserve what they get. This needs to go into all branches and let's re-tag and re-package 5.3 with this, Andrei's calloc fix, and the UPGRADING fixes. -Rasmus --- ## #44511 — Greg Beaver — 2009-06-27T02:05:19+00:00 URL: https://externals.io/message/44467#44511 · In reply to: #44497 Rasmus Lerdorf wrote: > And 10 years ago I'd be hacking on this for the next 3 hours, but right > now I am spending the next 3 hours picking up Carl from Lego Camp and > taking him to his piano lesson... What, no cello lesson? Greg --- ## #44518 — johannes@schlueters.de — 2009-06-27T11:30:08+00:00 URL: https://externals.io/message/44467#44518 · In reply to: #44470 Hi, > This freeze that you guys have implemented is frustrating, just branch > 5_3 into a release branch and Johannes can take selective fixes from > 5_3 as needed. In my experience - from projects I participated as well were I just observed - release branches with CVS often end with more pain than freezes. It is of course hard to predict what would happen in this project with these developers in this situation. And well, as said 5.3 is a quite big release and has many things where errors can be introduced and I guess we all want it out soonish as stable as possible ... > We all know your reasons for the freeze and agree with it but holding > up regular development is a PITA. HEAD is the development branch. 5.3 should only get stable stuff anyways. And I assume you are committing only well tested stuff to 5.3 which means you have some way of management outside CVS assisting you during development and testing of your stuff. About the extension of the freeze for the migration: I think we first should have a window for getting some fixes in before doing the migration so at least some of the backlog can be cleared. As far as I know there's n final complete migration plan and there might be people who want to play a little with the test repo once 5.3 is out. johannes --- Next page: https://externals.io/message/44467.md?page=2