# Towards 5.3.2 - Thread: https://externals.io/message/46300 - Original archive: https://news-web.php.net/php.internals/46300 - Started by johannes@php.net on 2009-12-07T13:37:49+00:00 - Messages: 36 - Page 1 of 2: messages 1 to 25 (25 per page, add `?page=N` to the URL) - Next page: https://externals.io/message/46300.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 --- ## #46300 — johannes@php.net — 2009-12-07T13:37:49+00:00 URL: https://externals.io/message/46300#46300 Hi, so, 5.3.1 out just a few weeks but due to the merge-based process and some delays in there the changelog for 5.3 is already quite long and so I'd like to restart the release process there soon. My current plan has one RC this week, one more before Christmas, maybe Tue 22nd, then a Christmas break, a RC early/mid January and release late January. I don't think we could be faster but having some RC before Christmas might get some people to test it on their new PCs they get, people who won't test otherwise, while on the other side I don't expect too much actual work being done during that time. Given the discussions and ongoing refactoring work I would keep the FPM SAPI out of 5.3.2 but aim for integration with 5.3.3. (Tony / Michael) As a process: In general I think the release branch approach is a good one while we had some trouble as there doesn't seem to be any software to really manage release branches, but the wiki evolved to a good enough merge tracker[1] imo. (The second problem with this approach was some personal distraction I had) Any comments? johannes [1] http://wiki.php.net/todo/php531/log --- ## #46301 — Ilia Alshanetsky — 2009-12-07T13:41:20+00:00 URL: https://externals.io/message/46300#46301 · In reply to: #46300 Johannes, While the separate branch release for 5.3.1 was a worthwhile experiment, I think it creates too much opportunity for missed patches and quite frankly makes the whole release process confusing and complicated. My personal preference would be that 5.3.2, not be released from a separate branch. > Hi, > > so, 5.3.1 out just a few weeks but due to the merge-based process and > some delays in there the changelog for 5.3 is already quite long and so > I'd like to restart the release process there soon. > > My current plan has one RC this week, one more before Christmas, maybe > Tue 22nd, then a Christmas break, a RC early/mid January and release > late January. I don't think we could be faster but having some RC before > Christmas might get some people to test it on their new PCs they get, > people who won't test otherwise, while on the other side I don't expect > too much actual work being done during that time. > > Given the discussions and ongoing refactoring work I would keep the FPM > SAPI out of 5.3.2 but aim for integration with 5.3.3. (Tony / Michael) > > As a process: In general I think the release branch approach is a good > one while we had some trouble as there doesn't seem to be any software > to really manage release branches, but the wiki evolved to a good enough > merge tracker[1] imo. (The second problem with this approach was some > personal distraction I had) > > Any comments? > > johannes > > > [1] http://wiki.php.net/todo/php531/log --- ## #46303 — Pierre Joye — 2009-12-07T13:46:43+00:00 URL: https://externals.io/message/46300#46303 · In reply to: #46301 2009/12/7 Ilia Alshanetsky : > Johannes, > > While the separate branch release for 5.3.1 was a worthwhile experiment, I think it creates too much opportunity for missed patches and quite frankly makes the whole release process confusing and complicated. My personal preference would be that 5.3.2, not be released from a separate branch. It was actually the exact opposite. We did not miss patches once we were synced. The way we tracked the patches also let us actually define what must go in and what not, avoiding the classical last minute bad patches. The key to success is to do not let go months between a commit and its merge to the release branch, which was a real pain when we began 5.3.1. Cheers, -- Pierre http://blog.thepimp.net | http://www.libgd.org --- ## #46304 — Lukas Kahwe Smith — 2009-12-07T13:48:27+00:00 URL: https://externals.io/message/46300#46304 · In reply to: #46301 > While the separate branch release for 5.3.1 was a worthwhile experiment, I think it creates too much opportunity for missed patches and quite frankly makes the whole release process confusing and complicated. My personal preference would be that 5.3.2, not be released from a separate branch. I remember that when I was RM that the need for code freezes was one of the most painful things to manage. So not having to deal with that seems like a very appealing target for all involved. As for risk of missed patches and confusion. I think Pierre did the best he could to improve the transparency of the process with the wiki page. However we still have plenty of ways to make this even clearer and more obvious to follow. Especially integration into the bug tracker (aka milestone support) would go a long way here. Making sure that every commit has a bug id attached (or if necessary gets a bug ticket created on the fly and the id injected into the commit) could also help. Obviously such infrastructure will not materialize over night, but I would urge everything to not drop the idea entirely. regards, Lukas Kahwe Smith mls@pooteeweet.org --- ## #46305 — Ilia Alshanetsky — 2009-12-07T13:50:18+00:00 URL: https://externals.io/message/46300#46305 · In reply to: #46303 Pierre, Actually patches were indeed missed, in fact we almost missed a security fix. As far as the wiki goes, most people don't even know it exists, let alone where to find it. Also, looking at the wiki there are a whole series of patches that did not go in into 5.3.1, that there is little indication as to why they didn't. > 2009/12/7 Ilia Alshanetsky : > > […] > > It was actually the exact opposite. We did not miss patches once we > were synced. The way we tracked the patches also let us actually > define what must go in and what not, avoiding the classical last > minute bad patches. The key to success is to do not let go months > between a commit and its merge to the release branch, which was a real > pain when we began 5.3.1. > > Cheers, > -- > Pierre > > http://blog.thepimp.net | http://www.libgd.org --- ## #46306 — Pierre Joye — 2009-12-07T13:54:24+00:00 URL: https://externals.io/message/46300#46306 · In reply to: #46305 Ilia, 2009/12/7 Ilia Alshanetsky : > Pierre, > > Actually patches were indeed missed, in fact we almost missed a security fix. Which? We did review *all* 5.3 commits before going final. >As far as the wiki goes, most people don't even know it exists If a PHP core developer does not know about it, then we have a serious problem. >, let alone where to find it. Also, looking at the wiki there are a whole series of patches that did not go in into 5.3.1, that there is little indication as to why they didn't. We can add a reason for the rejection (new features and non critical patches have been rejected when we were in the RC phase, obviously :) , but that does not mean the system is bad. Cheers, -- Pierre http://blog.thepimp.net | http://www.libgd.org --- ## #46308 — Lukas Kahwe Smith — 2009-12-07T13:58:38+00:00 URL: https://externals.io/message/46300#46308 · In reply to: #46306 > > […] > > If a PHP core developer does not know about it, then we have a serious problem. I think it was mentioned on this list sufficiently often, but then again it came along fairly ad hoc. However I do agree that the wiki is not the right place for this in the long run. Like I said, I believe the bug tracker is the place for this by adding milestone support. This would also be the natural place to note why a patch is not merged for example. regards, Lukas Kahwe Smith mls@pooteeweet.org --- ## #46310 — Ilia Alshanetsky — 2009-12-07T14:13:37+00:00 URL: https://externals.io/message/46300#46310 · In reply to: #46306 > Ilia, > > 2009/12/7 Ilia Alshanetsky : > > […] > > Which? We did review *all* 5.3 commits before going final. The max # of file uploads was almost missed. > > […] > > If a PHP core developer does not know about it, then we have a serious problem. There are at least 4 people I spoke with that didn't know about it, I would say there are probably more. --- ## #46311 — Pierre Joye — 2009-12-07T14:19:25+00:00 URL: https://externals.io/message/46300#46311 · In reply to: #46310 2009/12/7 Ilia Alshanetsky : > > > > > […] > > The max # of file uploads was almost missed. It was not, and we did not forget it because of the automatic TODOs in the wiki (it shows all commits in a list with their states, http://wiki.php.net/todo/php531/log) :-). > There are at least 4 people I spoke with that didn't know about it, I would say there are probably more. If one does not want to know something, then there is no way for us to make him cluefull. The wiki has been mentioned hundred of times in this list, but yes, one has to actually read the mails to get a clue :) Cheers, -- Pierre http://blog.thepimp.net | http://www.libgd.org --- ## #46312 — Lukas Kahwe Smith — 2009-12-07T14:19:58+00:00 URL: https://externals.io/message/46300#46312 · In reply to: #46310 > > […] > > There are at least 4 people I spoke with that didn't know about it, I would say there are probably more. Well that only means we need to make sure that developers know about stuff like this. Do we need an (irregular) newsletter to inform people? I mean we have had this problem as well with commit freezes, but there it was actually a bigger problem. If we do stick with the wiki for now .. then all that needs to happen is to inform relevant developers once .. and nothing breaks if they do not know about it at a fixed date .. like with a commit freeze. In other words, the problem might exist, but its solvable and is unrelated to using a branch or not. regards, Lukas Kahwe Smith mls@pooteeweet.org --- ## #46313 — Ilia Alshanetsky — 2009-12-07T14:21:37+00:00 URL: https://externals.io/message/46300#46313 · In reply to: #46311 > > […] > > It was not, and we did not forget it because of the automatic TODOs in > the wiki (it shows all commits in a list with their states, > http://wiki.php.net/todo/php531/log) :-). BS, I reminded Johannes about that patch right before the final RC, because it was still not merged. --- ## #46314 — Pierre Joye — 2009-12-07T14:27:53+00:00 URL: https://externals.io/message/46300#46314 · In reply to: #46313 2009/12/7 Ilia Alshanetsky : > > > > […] > > BS, I reminded Johannes about that patch right before the final RC, because it was still not merged. I think you should reconsider the way you see the whole thing. I did remind Johannes as well while reviewing the commits. That's nice that you did it as well as it just shows that the system worked, double safety. Now, about the way we do releases. Everyone agrees that is a mess, no real plan or ability to define a clear roadmap. 5.3.1 has shown that there is a way to solve that problem without influencing the day to day job of the other core developers while making the release process safer (no last minute breakage due to wild commits for example). There is stilll a lot to do to make this process better and friendly but we are on the right track. Cheers, -- Pierre http://blog.thepimp.net | http://www.libgd.org --- ## #46315 — Ilia Alshanetsky — 2009-12-07T14:34:30+00:00 URL: https://externals.io/message/46300#46315 · In reply to: #46314 > 2009/12/7 Ilia Alshanetsky : > > […] > > I think you should reconsider the way you see the whole thing. I did > remind Johannes as well while reviewing the commits. That's nice that > you did it as well as it just shows that the system worked, double > safety. If anything it shows the "system" had failed and aside from yourself and Johannes most developers have no idea what is and isn't part of the release. More over there is a whole pile patches that were not merged with no indication as to why... The amount of "no" and "?" is rather alarming, especially when there is no indicator as to why. Additionally, would be possible to get some clarity as to who is actually is the RM for the 5.3.X tree, first it was Johannes, then Johannes and Lukas, now you seem to be playing a big role in it. Can I (we) get some clarity around that. --- ## #46316 — johannes@php.net — 2009-12-07T14:34:33+00:00 URL: https://externals.io/message/46300#46316 · In reply to: #46313 > > […] > > BS, I reminded Johannes about that patch right before the final RC, because it was still not merged. Which only the value in the sample php.ini files was, the fix itself was. And no I don't claim it was perfect and I opened this discussion for the purpose to decide on this. I *think* if we all want the release branch is the better process to create a stable release with less risk. But I can live with either approaches. johannes --- ## #46318 — Pierre Joye — 2009-12-07T14:42:20+00:00 URL: https://externals.io/message/46300#46318 · In reply to: #46315 2009/12/7 Ilia Alshanetsky : > If anything it shows the "system" had failed and aside from yourself and Johannes most developers have no idea what is and isn't part of the release.  More over there is a whole pile patches that were not merged with no indication as to why... The amount of "no" and "?" is rather alarming, especially when there is no indicator as to why. Wait, and now developers do not read NEWS either? Oh my... it is worst that I initially thought :) > Additionally, would be possible to get some clarity as to who is actually is the RM for the 5.3.X tree, first it was Johannes, then Johannes and Lukas, now you seem to be playing a big role in it. Can I (we) get some clarity around that. Given that I work full time on PHP itself (or closely related projects, and not only for the windows part of them), I give a hand to Johannes to keep 5.3 releases on track, merges, etc. I don't think there is such a need of a clarification or do you consider that having people helping other developers or RM cannot happen without an official statement on the mailing list ? :) Cheers, -- Pierre http://blog.thepimp.net | http://www.libgd.org --- ## #46319 — Ilia Alshanetsky — 2009-12-07T14:51:50+00:00 URL: https://externals.io/message/46300#46319 · In reply to: #46318 > 2009/12/7 Ilia Alshanetsky : > > > […] > > Wait, and now developers do not read NEWS either? Oh my... it is worst > that I initially thought :) The NEWS file would tell me why patches were not merged? Also the news file does not contain entries about many fixes that don't have corresponding bug # attached to them. As I recall the 5.3.1 NEWS entry were merged back to the PHP_5_3 6 days after the release by you ;-). --- ## #46320 — Derick Rethans — 2009-12-07T14:53:15+00:00 URL: https://externals.io/message/46300#46320 · In reply to: #46301 > While the separate branch release for 5.3.1 was a worthwhile > experiment, I think it creates too much opportunity for missed patches > and quite frankly makes the whole release process confusing and > complicated. My personal preference would be that 5.3.2, not be > released from a separate branch. I second that; I had no clue what was going on, and I only found out about this wiki thing afterwards. Please get things back to normal like we do with 5.2. Derick -- http://derickrethans.nl | http://ezcomponents.org | http://xdebug.org twitter: @derickr --- ## #46321 — Pierre Joye — 2009-12-07T14:55:48+00:00 URL: https://externals.io/message/46300#46321 · In reply to: #46319 2009/12/7 Ilia Alshanetsky : > The NEWS file would tell me why patches were not merged? Also the news file does not contain entries about many fixes that don't have corresponding bug # attached to them. > As I recall the 5.3.1 NEWS entry were merged back to the PHP_5_3 6 days after the release by you ;-). Ok, so what you are arguing about is that you don't know why something was not merged. That's something we like to improve but it has nothing to do with the extra branch, absolutely nothing. Cheers, -- Pierre http://blog.thepimp.net | http://www.libgd.org --- ## #46322 — Ilia Alshanetsky — 2009-12-07T14:59:42+00:00 URL: https://externals.io/message/46300#46322 · In reply to: #46321 Pierre, It has everything to do with the separate branch. Our current approach, (as flawed as it maybe) ensures patches are not missed, since there is no separate branch, so patches go into the release tree. With the new approach if something is not merged it is not part of the release. This also makes it confusing for the users, since the dev fixing the bug indicates on the bug tracker the issue was resolved, and will be part of the next release. And then the next release comes out and the bug/issue is still there... > 2009/12/7 Ilia Alshanetsky : > > > […] > > Ok, so what you are arguing about is that you don't know why something > was not merged. That's something we like to improve but it has nothing > to do with the extra branch, absolutely nothing. > > Cheers, > -- > Pierre > > http://blog.thepimp.net | http://www.libgd.org --- ## #46323 — Larry Adams — 2009-12-07T15:05:34+00:00 URL: https://externals.io/message/46300#46323 · In reply to: #46321 Pierre Joye wrote: > 2009/12/7 Ilia Alshanetsky : > > > > […] > > Ok, so what you are arguing about is that you don't know why something > was not merged. That's something we like to improve but it has nothing > to do with the extra branch, absolutely nothing. > > Cheers, > Pierre, What's the status of the SNMP fixes? I see that SNMP is still not in the 5.3.x code. Larry --- ## #46324 — Pierre Joye — 2009-12-07T15:08:10+00:00 URL: https://externals.io/message/46300#46324 · In reply to: #46322 2009/12/7 Ilia Alshanetsky : > Pierre, > > It has everything to do with the separate branch. Our current approach, (as flawed as it maybe) ensures patches are not missed, since there is no separate branch, so patches go into the release tree. With the new approach if something is not merged it is not part of the release. This also makes it confusing for the users, since the dev fixing the bug indicates on the bug tracker the issue was resolved, and will be part of the next release. And then the next release comes out and the bug/issue is still there... Ok, so we are running in circle. We agreed on that: - we need to add a field to explain why a patch was not merged - a real bug tracker - with roadmap - allow to set a bug as part of a given release roadmap, like when a patch is commited to the dev branches, it can be set to "5.3.2" so the RM can appove merge it - be sure that the merge commits are shown in the bug reports as well However, given that: - we did NOT miss any patches in 5.3.1 - the process was open, mails have been sent to the list, etc. - the deadlines were respected, 1st time in 5.3 releases history I do not understand why you keep saying that it was a major mistake to do it this way. I can understand that the chaotic way fits more to your ideas about how things should work however it totally fails to actually get 3rd parties involved more deeply in our developments (be QA or to integrate latest releases to their products, like most unix distros). What I suggest is to do it again the same way for 5.3.2, I will improve the tools to make it more transparent and full fills your requests (except the bug trackes, which is another major issue that we will have to address very soon as well). Then we can have this discussion again. The reason is that both Johannes and I were happy (not 100% but more than 50% :) with it and it allows us to sleep better during the release phases. Cheers, -- Pierre http://blog.thepimp.net | http://www.libgd.org --- ## #46325 — Pierre Joye — 2009-12-07T15:10:23+00:00 URL: https://externals.io/message/46300#46325 · In reply to: #46323 hi, > What's the status of the SNMP fixes?  I see that SNMP is still not in the > 5.3.x code. Don't hijack threads with off topic questions, thanks (and use text email :). I suppose you refer to the netsmnp library, then I return you the question, what's the status of your work and tests? Cheers, -- Pierre http://blog.thepimp.net | http://www.libgd.org --- ## #46326 — David Soria Parra — 2009-12-07T15:11:00+00:00 URL: https://externals.io/message/46300#46326 · In reply to: #46305 As Lukas pointed out, both approaches have flaws, but I think the new merging approach is much cleaner and prevents people from committing during a freeze. Although the wiki might not be the perfect place to do things, I think the general approach is good. Core developers should know what's going on in the wiki, or at least don't complain. Cheers > Pierre, > > Actually patches were indeed missed, in fact we almost missed a security fix. As far as the wiki goes, most people don't even know it exists, let alone where to find it. Also, looking at the wiki there are a whole series of patches that did not go in into 5.3.1, that there is little indication as to why they didn't. > > > > > > […] --- ## #46327 — Ilia Alshanetsky — 2009-12-07T15:16:21+00:00 URL: https://externals.io/message/46300#46327 · In reply to: #46325 > hi, > > > > > […] > > Don't hijack threads with off topic questions, thanks (and use text email :). > Eh? How is his question off topic? As far as fixes this could be what he is referring to Fixed bug #49990 (SNMP3 warning message about security level printed twice). --- ## #46328 — Pierre Joye — 2009-12-07T15:22:08+00:00 URL: https://externals.io/message/46300#46328 · In reply to: #46327 2009/12/7 Ilia Alshanetsky : > > > > > […] > > Eh? How is his question off topic? As far as fixes this could be what he is referring to Because it has nothing to do with PHP releases or ext/snmp directly but the snmp library on Windows for PHP 5.3 and later. We don't use because the latest smnp releases do not work on Windows. Cheers, -- Pierre http://blog.thepimp.net | http://www.libgd.org --- Next page: https://externals.io/message/46300.md?page=2