# trunk is alive and open - Thread: https://externals.io/message/47479 - Original archive: https://news-web.php.net/php.internals/47479 - Started by Derick Rethans on 2010-03-23T16:04:57+00:00 - Messages: 55 - Page 1 of 3: messages 1 to 25 (25 per page, add `?page=N` to the URL) - Next page: https://externals.io/message/47479.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 --- ## #47479 — Derick Rethans — 2010-03-23T16:04:57+00:00 URL: https://externals.io/message/47479#47479 Hello, I've just created trunk for 5.3 again. I've set the version to 5.3.99-dev as to explicitly not decide on whether there will be 5.4 or 6.0 next. New features should go to trunk; but anything other then trivial additions should require an RFC and discussion. I think Antony has the FPM RFC ready to show what sort of stuff would be useful to have. I'll let Antony start a thread to discuss it (although I doubt there needs to be a lot of discussion for it). I think Ilia mentioned that he wanted to do one more normal 5.2 release, after which it will be "security fix only". So for now my suggestion would be: - new features to to trunk - bug fixes go to 5.2 and 5.3. Let's see what cool stuff we can come up with for the next version! with kind regards, Derick -- http://derickrethans.nl | http://xdebug.org Like Xdebug? Consider a donation: http://xdebug.org/donate.php twitter: @derickr and @xdebug --- ## #47480 — Pierre Joye — 2010-03-23T16:11:51+00:00 URL: https://externals.io/message/47479#47480 · In reply to: #47479 hi, I would rather have some kind of rules defined before opening trunk again (or the pandora box). That's what we are discussing right now. May I know why you choosed that now is the right time to do it and declare it open? Cheers, > Hello, > > I've just created trunk for 5.3 again. I've set the version to > 5.3.99-dev as to explicitly not decide on whether there will be 5.4 or > 6.0 next. > > New features should go to trunk; but anything other then trivial > additions should require an RFC and discussion. I think Antony has the > FPM RFC ready to show what sort of stuff would be useful to have. I'll > let Antony start a thread to discuss it (although I doubt there needs to > be a lot of discussion for it). > > I think Ilia mentioned that he wanted to do one more normal 5.2 release, > after which it will be "security fix only". So for now my suggestion > would be: > > - new features to to trunk > - bug fixes go to 5.2 and 5.3. > > Let's see what cool stuff we can come up with for the next version! > > with kind regards, > Derick > -- > http://derickrethans.nl | http://xdebug.org > Like Xdebug? Consider a donation: http://xdebug.org/donate.php > twitter: @derickr and @xdebug > > -- > > > > -- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org --- ## #47481 — Rasmus Lerdorf — 2010-03-23T16:21:48+00:00 URL: https://externals.io/message/47479#47481 · In reply to: #47480 > hi, > > I would rather have some kind of rules defined before opening trunk > again (or the pandora box). That's what we are discussing right now. > May I know why you choosed that now is the right time to do it and > declare it open? We have rules. Large features, write an RFC and we discuss it. Small and obvious improvements follow commit-then-review as before. We don't need more complicated rules than that. -Rasmus --- ## #47482 — Pierre Joye — 2010-03-23T16:32:52+00:00 URL: https://externals.io/message/47479#47482 · In reply to: #47481 > > > […] > > We have rules.  Large features, write an RFC and we discuss it.  Small > and obvious improvements follow commit-then-review as before.  We don't > need more complicated rules than that. Right, but what I mean was about releases. But it seems that it is what Derick meant too. trunk remains trunk (development), not a release branch for a hypothetic version. How the next version will be done and when is another discussion. And I tend to agree with you about complex processes. However we do need to drastically improve the way we do or plan releases. It can be done without affecting the way we work, only the way we release and the releases frequency. Cheers, -- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org --- ## #47483 — Lukas Kahwe Smith — 2010-03-23T16:36:02+00:00 URL: https://externals.io/message/47479#47483 · In reply to: #47481 > > > […] > > We have rules. Large features, write an RFC and we discuss it. Small > and obvious improvements follow commit-then-review as before. We don't > need more complicated rules than that. Yeah, but I still think it would be a good idea to figure out lets say 3-5 big time features that we focus on for the next release and a rough timeline for the next release. For example next major release Q2/Q3 2011: - traits - bundling APC - large file and big number support - ob patch - unicode improvements (*) (*) lets see what ideas we come up with, might turn out to be the big thing or maybe just a small incremental tweak here and there regards, Lukas Kahwe Smith mls@pooteeweet.org --- ## #47484 — Rasmus Lerdorf — 2010-03-23T16:38:22+00:00 URL: https://externals.io/message/47479#47484 · In reply to: #47482 > > > […] > > Right, but what I mean was about releases. But it seems that it is > what Derick meant too. trunk remains trunk (development), not a > release branch for a hypothetic version. > > How the next version will be done and when is another discussion. And > I tend to agree with you about complex processes. However we do need > to drastically improve the way we do or plan releases. It can be done > without affecting the way we work, only the way we release and the > releases frequency. Releases have nothing to do with this. trunk is where new development happens. Which parts end up in which releases is completely separate from this. Things may be backported to 5.3, or we do a 5.4 release branch off of trunk at some point, or we charge ahead and do a full 6.0 off of trunk. We won't know that until we get some work done in trunk, and the first step is to have an open trunk. -Rasmus --- ## #47485 — Derick Rethans — 2010-03-23T16:38:28+00:00 URL: https://externals.io/message/47479#47485 · In reply to: #47479 > I've just created trunk for 5.3 again. I've set the version to > 5.3.99-dev as to explicitly not decide on whether there will be 5.4 or > 6.0 next. I've also enabled snapshots for trunk, they are called php-trunk-.*. See them at http://snaps.php.net/ regards, Derick -- http://derickrethans.nl | http://xdebug.org Like Xdebug? Consider a donation: http://xdebug.org/donate.php twitter: @derickr and @xdebug --- ## #47487 — Richard Quadling — 2010-03-23T16:47:34+00:00 URL: https://externals.io/message/47479#47487 · In reply to: #47485 > > > > […] > > I've also enabled snapshots for trunk, they are called > php-trunk-.*. See them at http://snaps.php.net/ > > regards, > Derick > > -- > http://derickrethans.nl | http://xdebug.org > Like Xdebug? Consider a donation: http://xdebug.org/donate.php > twitter: @derickr and @xdebug > > -- > > > > Are the win32 snapshots going to come back online again? Re:http://bugs.php.net/bug.php?id=50821 Regards, Richard. -- ----- Richard Quadling "Standing on the shoulders of some very clever giants!" EE : http://www.experts-exchange.com/M_248814.html EE4Free : http://www.experts-exchange.com/becomeAnExpert.jsp Zend Certified Engineer : http://zend.com/zce.php?c=ZEND002498&r=213474731 ZOPA : http://uk.zopa.com/member/RQuadling --- ## #47488 — Pierre Joye — 2010-03-23T16:55:18+00:00 URL: https://externals.io/message/47479#47488 · In reply to: #47487 yes On Tue, Mar 23, 2010 at 5:47 PM, Richard Quadling wrote: > > > […] > > Are the win32 snapshots going to come back online again? > Re:http://bugs.php.net/bug.php?id=50821 > > Regards, > > Richard. > > -- > ----- > Richard Quadling > "Standing on the shoulders of some very clever giants!" > EE : http://www.experts-exchange.com/M_248814.html > EE4Free : http://www.experts-exchange.com/becomeAnExpert.jsp > Zend Certified Engineer : http://zend.com/zce.php?c=ZEND002498&r=213474731 > ZOPA : http://uk.zopa.com/member/RQuadling > > -- > > > > -- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org --- ## #47489 — Rasmus Lerdorf — 2010-03-23T16:59:17+00:00 URL: https://externals.io/message/47479#47489 · In reply to: #47483 > > > > > […] > > > Yeah, but I still think it would be a good idea to figure out lets say 3-5 big time features that we focus on for the next release and a rough timeline for the next release. > > For example next major release Q2/Q3 2011: > - traits > - bundling APC > - large file and big number support > - ob patch > - unicode improvements (*) > > (*) lets see what ideas we come up with, might turn out to be the big thing or maybe just a small incremental tweak here and there We don't need timelines right now. What we need is some hacking time and to bring some fun back into PHP development. It hasn't been fun for quite a while. Once we have a body of new interesting stuff, we can start pondering releases with a release branch off of trunk that might cherry-pick a subset of the work in trunk and you can start making your lists and setting timelines at that point. -Rasmus --- ## #47490 — Lukas Kahwe Smith — 2010-03-23T17:05:42+00:00 URL: https://externals.io/message/47479#47490 · In reply to: #47489 > > > […] > > We don't need timelines right now. What we need is some hacking time > and to bring some fun back into PHP development. It hasn't been fun for > quite a while. Once we have a body of new interesting stuff, we can > start pondering releases with a release branch off of trunk that might > cherry-pick a subset of the work in trunk and you can start making your > lists and setting timelines at that point. Well .. as you can see from the above list, this is already a backlog of fun stuff that is pretty far along. This is why I am saying lets get to a release often cycle, where people can work on stuff and be sure to get it in at a reasonable timeframe and also prevent stuff like PHP6/PHP5.3 from happening again. And since we are talking about cherry picking features from trunk into the next release branch (along with feature branches), we are back to a situation where fun hacking can always happen. But imho we have enough features on the table that we can start cherry picking now ... of course we can still fast track other stuff later on .. but its also not that bad that after a release we already have a full pipeline to plan the next release. regards, Lukas Kahwe Smith mls@pooteeweet.org --- ## #47492 — Rasmus Lerdorf — 2010-03-23T17:15:20+00:00 URL: https://externals.io/message/47479#47492 · In reply to: #47490 > > > > > […] > > > Well .. as you can see from the above list, this is already a backlog of fun stuff that is pretty far along. This is why I am saying lets get to a release often cycle, where people can work on stuff and be sure to get it in at a reasonable timeframe and also prevent stuff like PHP6/PHP5.3 from happening again. > > And since we are talking about cherry picking features from trunk into the next release branch (along with feature branches), we are back to a situation where fun hacking can always happen. But imho we have enough features on the table that we can start cherry picking now ... of course we can still fast track other stuff later on .. but its also not that bad that after a release we already have a full pipeline to plan the next release. Until someone does the work and commits code to trunk complete with working tests we don't have anything except a list of theoretical features. We don't know if any of the things on your list are actually feasible yet giving the level of interest from the various people behind those items. I know for APC, for example, both Gopal and Brian Shire are off doing other things right now, so we may not be able to get that list item integrated anytime soon, if ever. What is the current state of the traits patch? We have 2 different large number approaches. Those guys need to write their rfcs and compare notes. The ob patch seems close, but it breaks on some operating systems, so unless someone has time to look into that, that one isn't feasible either. And we may end up seeing a number of other interesting and complete patches pop up. My point is that your eventual list should come from things that have been committed to trunk and survived review and tests. -Rasmus --- ## #47494 — Kalle Sommer Nielsen — 2010-03-23T17:44:36+00:00 URL: https://externals.io/message/47479#47494 · In reply to: #47479 Hi Derick 2010/3/23 Derick Rethans : > Hello, > > I've just created trunk for 5.3 again. I've set the version to > 5.3.99-dev as to explicitly not decide on whether there will be 5.4 or > 6.0 next. Great! > > New features should go to trunk; but anything other then trivial > additions should require an RFC and discussion. I think Antony has the > FPM RFC ready to show what sort of stuff would be useful to have. I'll > let Antony start a thread to discuss it (although I doubt there needs to > be a lot of discussion for it). Im assuming that we are still removing the stuff that we deprecated in 5.3 and removed in the old trunk? If thats the case then I will work on merging those removed features like safe_mode and so on out. -- regards, Kalle Sommer Nielsen kalle@php.net --- ## #47495 — Lukas Kahwe Smith — 2010-03-23T17:47:36+00:00 URL: https://externals.io/message/47479#47495 · In reply to: #47494 > Hi Derick > > 2010/3/23 Derick Rethans : > > […] > > Im assuming that we are still removing the stuff that we deprecated in > 5.3 and removed in the old trunk? If thats the case then I will work > on merging those removed features like safe_mode and so on out. uhm no .. i think for that stuff we have to wait until we decide if the next version is 6.0 or 5.4 regards, Lukas Kahwe Smith mls@pooteeweet.org --- ## #47496 — David Soria Parra — 2010-03-23T17:49:10+00:00 URL: https://externals.io/message/47479#47496 · In reply to: #47494 > > […] > > Im assuming that we are still removing the stuff that we deprecated in > 5.3 and removed in the old trunk? If thats the case then I will work > on merging those removed features like safe_mode and so on out. no please wait, if it's a 6.0 then probably yes, if it's a 5.4 then probably no. --- ## #47497 — johannes@php.net — 2010-03-23T18:08:39+00:00 URL: https://externals.io/message/47479#47497 · In reply to: #47494 Hi, > Im assuming that we are still removing the stuff that we deprecated in > 5.3 and removed in the old trunk? If thats the case then I will work > on merging those removed features like safe_mode and so on out. I think that's, like other stuff, a case-by-case decision. For example I don't think it's a good idea to drop magic_quotes in a version which doesn't include a big BC break. Unfortunately many applications are half-secure by this setting but absolutely insecure once that's changed and people update without reading docs - especially if a quick test shows no errors. With finally dropping register_globals I won't have problems. johannes --- ## #47498 — johannes@php.net — 2010-03-23T18:16:24+00:00 URL: https://externals.io/message/47479#47498 · In reply to: #47479 > Hello, > > I've just created trunk for 5.3 again. I've set the version to > 5.3.99-dev as to explicitly not decide on whether there will be 5.4 or > 6.0 next. As I mentioned on IRC and in previous threads: I'd prefer to call it 5.4 - we can still increase the number as needed but we will almost certainly break ABIs/APIs and need to change API no.s and changing the second digit might reduce some confusion by bug reporters ... johannes --- ## #47517 — Stefan Marr — 2010-03-23T21:08:13+00:00 URL: https://externals.io/message/47479#47517 · In reply to: #47492 Hi: > > […] > What is the current state > of the traits patch? We have 2 different large number approaches. > Those guys need to write their rfcs and compare notes. As far as I am concerned, traits, as proposed in the RFC[1], are implemented and it would be possible to merge them in. However, as far as I remember, there was no consensus on several details of this proposal. So, what I can do is to ask you guys to reread the proposal and checkout a copy from [2] to look for instance at the test cases, and tell me what you don't like. Best regards Stefan [1] http://wiki.php.net/rfc/horizontalreuse [2] http://github.com/gron/php-src/tree/PHP_5_3-traits -- Stefan Marr Software Languages Lab Vrije Universiteit Brussel Pleinlaan 2 / B-1050 Brussels / Belgium http://soft.vub.ac.be/~smarr Phone: +32 2 629 2974 Fax: +32 2 629 3525 --- ## #47522 — Andi Gutmans — 2010-03-23T22:04:04+00:00 URL: https://externals.io/message/47479#47522 · In reply to: #47479 > -----Original Message----- > From: Derick Rethans [mailto:derick@php.net] > Sent: Tuesday, March 23, 2010 9:05 AM > To: PHP Developers Mailing List > Subject: [PHP-DEV] trunk is alive and open > > Hello, > > I've just created trunk for 5.3 again. I've set the version to 5.3.99-dev as to > explicitly not decide on whether there will be 5.4 or > 6.0 next. > > New features should go to trunk; but anything other then trivial additions > should require an RFC and discussion. I think Antony has the FPM RFC ready > to show what sort of stuff would be useful to have. I'll let Antony start a > thread to discuss it (although I doubt there needs to be a lot of discussion for > it). > > I think Ilia mentioned that he wanted to do one more normal 5.2 release, > after which it will be "security fix only". So for now my suggestion would be: > > - new features to to trunk > - bug fixes go to 5.2 and 5.3. > > Let's see what cool stuff we can come up with for the next version! What about defining a release manager for the next release? I think that is an important aspect of moving things forward. I also thought the dual RM in PHP 5.3 worked quite well although it is not necessarily a must. I do think we want to avoid ending up with another stale trunk. As I mentioned in my previous note it's important to have a reasonable scope for the next upcoming major (5.4/6.0) release and make sure we do have the right amount of discussions re: new functionality committed. So I do propose that in the coming weeks (as 80% of the ideas surface) the RMs create a roadmap for the next version which clearly identifies the must-haves and should-haves. This can always be changed/tweaked (as we always have in the past) but it sets the tone for pushing out functionality sooner rather than later (i.e. if a should-have is still not quite fully baked but all must-haves are done then ship). As we saw with PHP 5.3 it ended up being a pretty major version and it delivers a lot of incremental value. So it was good it didn't wait for every single idea. Andi --- ## #47533 — Lukas Kahwe Smith — 2010-03-23T23:02:07+00:00 URL: https://externals.io/message/47479#47533 · In reply to: #47492 > My point is that your eventual list should come from things that have > been committed to trunk and survived review and tests. Sure, its only that many patches and todo items have been lingering (hello frustration?) because of the trunk situation, because we decided to then focus on 5.3 etc. Stuff like traits, the OB fixes have been flying around for a long time and just didnt get the last attention. LFS and big ints have also been on the roadmap for ages and it seems like at least for big numbers there is even a patch. If we now spend a few months to work on fun stuff (which is what we have trunk for) instead of focusing on getting this stuff finalized we are just delaying these patches. We all know that when we get towards crunch time we finalize patches way more quickly, than when we say "oh lets hack on stuff for a while and see where we get". Again, for "fun development" there is trunk or feature branches. But we have enough stuff for a new major release right at our finger tips to start thinking about what our next release should look like instead of waiting for another 3-6 months which would obviously also imply a delay of at least 6-9 months (because big new features we come up with in the next 3-6 months will need their time to make it into trunk as well). So sure lets take until the end of April to think about a set of patches we want, but please lets not spend the next 3-6 months coming up with entirely new ideas to put into the next major update. Then again this might just be a misunderstanding and you are also just talking about giving some key features a few weeks to make it into trunk and in a state where we feel fairly certain that we can fix any issues should there still be any. In conclusion: There should of course be fun in just hacking out cool stuff, but I think for most developers a big part of the fun is actually seeing your ideas in a stable release. regards, Lukas Kahwe Smith mls@pooteeweet.org --- ## #47537 — Rasmus Lerdorf — 2010-03-24T04:06:18+00:00 URL: https://externals.io/message/47479#47537 · In reply to: #47533 > In conclusion: > There should of course be fun in just hacking out cool stuff, but I think for most developers a big part of the fun is actually seeing your ideas in a stable release. Exactly. But that means we need to wait and see which developers step up and actually commit their code to trunk. You can create all the shopping lists you want and set all the dates you want, but they are irrelevant until we see some of this stuff hashed out via rfcs and then reviewed once actually committed to trunk. PHP development stalled in large part because we had lists of features without developers passionate about those features. So, less lists, and more coding for a while, please. We've got 2 small commits to trunk so far. I switched our default charset from ISO-8859-1 to UTF-8, and Michael added FNV hashing. Both minor changes, but we need to encourage more of these smaller incremental improvements in the dev branch and not discourage them because they weren't on a list somewhere before a certain date. Release dates slide because of a lack of developers, not because we have too many people committing stuff. Having a lot of people committing code is a good problem to have and the release manager(s) will sort it out eventually. -Rasmus --- ## #47551 — Lukas Kahwe Smith — 2010-03-24T10:02:37+00:00 URL: https://externals.io/message/47479#47551 · In reply to: #47522 > What about defining a release manager for the next release? I think that > is an important aspect of moving things forward. I also thought the dual > RM in PHP 5.3 worked quite well although it is not necessarily a must. Yeah, lets get that clarified. Derick has stepped up and seems quite committed and nobody seemed to oppose him RMing the next release. In case he feels he needs support he can propose a co-RM, after all its important that the two RM's know and trust each other well so that they can speak with a consistent voice. regards, Lukas Kahwe Smith mls@pooteeweet.org --- ## #47552 — Pierre Joye — 2010-03-24T10:08:30+00:00 URL: https://externals.io/message/47479#47552 · In reply to: #47551 hi, > > > > > […] > > > Yeah, lets get that clarified. Derick has stepped up and seems quite committed and nobody seemed to oppose him RMing the next release. In case he feels he needs support he can propose a co-RM, after all its important that the two RM's know and trust each other well so that they can speak with a consistent voice. As I think it is still a bit early to design RMs, I am still in favour of David and you. Or David and someone else with good communication skills. You suggested Chris and I think he could do a great job. My only worry is his time availability. But I'm definitively not in favour of Derick, he has been a RM already, let give newer people a chance. Cheers, -- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org --- ## #47555 — Zeev Suraski — 2010-03-24T10:37:49+00:00 URL: https://externals.io/message/47479#47555 · In reply to: #47552 At 12:08 24/03/2010, Pierre Joye wrote: > > […] > quite committed and nobody seemed to oppose him RMing the next > release. In case he feels he needs support he can propose a co-RM, > after all its important that the two RM's know and trust each other > well so that they can speak with a consistent voice. > >As I think it is still a bit early to design RMs, I am still in favour >of David and you. Or David and someone else with good communication >skills. You suggested Chris and I think he could do a great job. My >only worry is his time availability. But I'm definitively not in >favour of Derick, he has been a RM already, let give newer people a >chance. FWIW I too want to see you co-RMing. I think you being there, alongside someone else can bring great balance to the release. Zeev --- ## #47558 — Lukas Kahwe Smith — 2010-03-24T11:12:59+00:00 URL: https://externals.io/message/47479#47558 · In reply to: #47552 > skills. You suggested Chris and I think he could do a great job. My Just to clarify as I mentioned this on IRC and not on here. I think it would be great to have Chris Jones do the "organizational" co-RM. For one I have great trust in him keeping a good overview of the priorities, plus he can also give some technical input, where I for example couldn't. Furthermore I was co-RM in the last release, we all know power corrupts so its good to rotate :) For those who might be concerned that he is to embedded at Oracle, I actually think its quite the opposite. I think it would be great for PHP to have him take an "official" role. I have full trust in his integrity and so it might be also a good signal after the entire PDO2 CLA debacle that we do have trust in working with people from big corps. regards, Lukas Kahwe Smith mls@pooteeweet.org --- Next page: https://externals.io/message/47479.md?page=2