# Moving forward: PHP 5.5 - Thread: https://externals.io/message/62903 - Original archive: https://news-web.php.net/php.internals/62903 - Started by David Soria Parra on 2012-09-08T11:49:13+00:00 - Messages: 19 - 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 --- ## #62903 — David Soria Parra — 2012-09-08T11:49:13+00:00 URL: https://externals.io/message/62903#62903 Hi internals, it's been a great eight months now for PHP 5.4. We released 5.4.0 final in february and since then we were able to deliver a new PHP version every month (thanks to the hard work from stas). As most people know we do not include patches in 5.4 that will break backwards compatibility. Those patches are in the 5.5 branch and we are also stockpiling some new features. We have implementations for foreachlist, generators, hash_pbkdf2 and others are likely to get included in the next weeks like the simplified password hashing API. Following the release process RFC, I would like to start discussing the beginning of the 5.5. series, that can include new features, do bc breaks if necessary and overall provide a smooth move to a new series without having the branches diverge for years and years again (like 5.4 and 5.3). Last but not least, 5.3 is out since 2009 and it would be good to put the series into a security fix only mode and give it an eol. So I proposed to start off with 5.5 and focus on it, so we can get a release going till Feb/March 2013. As with every new release minor release (read minor as the Y in 5.Y.Z), we choose a new RM. We had quite some confusion and debates around this topic the last time, so I'll just go ahead and propose somebody right away for the job. I would like to go ahead and propose Julien Pauli as the RM for 5.5. He is an active member of the PHP.net community, has deep knowledge of the internals and the necessary backing from his company to be able to dedicate the time needed to do the job. Knowing that things are kindof rough at the start, I am willing to help out with intial releases, reviews and settings things up until they can be handled by one person (which is pretty much the state of 5.4 atm). If you can think of a better candidate or want to step up, feel free to do so. Let's keep things simple here, stay on topic and debate if we want to start with 5.5 and who can RM it. - David --- ## #62904 — Florian Anderiasch — 2012-09-08T12:03:54+00:00 URL: https://externals.io/message/62903#62904 · In reply to: #62903 > Let's keep things simple here, stay on topic and debate > if we want to start with 5.5 and who can RM it. Hey, sounds like a really good plan and apart from the probably most-often named disadvantage, getting people to switch (hard enough to get minor upgrades rolled out) I'm very much looking forward to this :) Greetings, Florian --- ## #62905 — Pierre Joye — 2012-09-08T14:15:43+00:00 URL: https://externals.io/message/62903#62905 · In reply to: #62903 Hi! > As most people know we do not include patches in 5.4 that will break > backwards compatibility. We do not include them anywhere in any future 5.x release either. That's clearly define in the RFC and we won't change that. Feedbacks from users on that is clear and loud, best decision ever. > Those patches are in the 5.5 branch and we > are also stockpiling some new features. There is o 5.5 branch, there is master. Master is the development branch and as such can have such breakages. It does not mean that we have these BC breaks in 5.5. 5.5 should be based on 5.4 with the feature additions and improvements we want in, but definitively not with BC breaks. > We have implementations for > foreachlist, generators, hash_pbkdf2 and others are likely to get included > in the next weeks like the simplified password hashing API. > > Following the release process RFC, I would like to start discussing the > beginning of the 5.5. series, that can include new features, do bc breaks > if necessary and overall provide a smooth move to a new series without > having the branches diverge for years and years again (like 5.4 and 5.3). > Last but not least, 5.3 is out since 2009 and it would be good to put > the series into a security fix only mode and give it an eol. Yes, let start the 5.3 EOL discussion too and decide when it will stop, or better said, end the discussion as we began it earlier this year :) > As with every new release minor release (read minor as the Y in 5.Y.Z), > we choose a new RM. We had quite some confusion and debates around this > topic the last time, so I'll just go ahead and propose somebody right > away for the job. Two persons, actually. > I would like to go ahead and propose Julien Pauli as the RM for 5.5. Huge +1. When we discussed that, you wanted to give up your role with 5.4 (one is enough at this point) and be co RM for 5.5. Did you change your mind? Cheers, Pierre --- ## #62906 — David Soria Parra — 2012-09-08T14:20:13+00:00 URL: https://externals.io/message/62903#62906 · In reply to: #62905 > Hi! > > > > > > […] > > We do not include them anywhere in any future 5.x release either. > That's clearly define in the RFC and we won't change that. Feedbacks > from users on that is clear and loud, best decision ever. I agree. I missed the point that 5.5 should not include bc breaks either. > > […] > > There is o 5.5 branch, there is master. Master is the development > branch and as such can have such breakages. It does not mean that we > have these BC breaks in 5.5. 5.5 should be based on 5.4 with the > feature additions and improvements we want in, but definitively not > with BC breaks. > > […] > > Two persons, actually. > > > […] > > Huge +1. > > When we discussed that, you wanted to give up your role with 5.4 (one > is enough at this point) and be co RM for 5.5. Did you change your > mind? As some people are confused by what I mean with what I would do. I can help with 5.5 and be the Co-RM again. The reason is simple, while the main RM is bound to the series for 2-3 years, Lukas back then and now I realize that after the first bumpy months it's a fairly straight forward job (particularly thanks to the release process) and I am sure Stas can manage 5.4 on it's own (and in case he is away for two weeks i can still run the process). At that point I am bascially just doing the announcements for 5.4. --- ## #63023 — David Soria Parra — 2012-09-17T08:09:42+00:00 URL: https://externals.io/message/62903#63023 · In reply to: #62903 > Hi internals, > I would like to go ahead and propose Julien Pauli as the RM for 5.5. He > is an active member of the PHP.net community, has deep knowledge of > the internals and the necessary backing from his company to be able to > dedicate the time needed to do the job. Knowing that things are kindof > rough at the start, I am willing to help out with intial releases, > reviews and settings things up until they can be handled by one person > (which is pretty much the state of 5.4 atm). A last bump on that. So nobody complained so far, I think Julien and I can go ahead and start with 5.5 as soon as possible. --- ## #63024 — Pierre Joye — 2012-09-17T08:15:52+00:00 URL: https://externals.io/message/62903#63024 · In reply to: #63023 > > > […] > > A last bump on that. So nobody complained so far, I think Julien and > I can go ahead and start with 5.5 as soon as possible. Hell yeah :) -- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org --- ## #63025 — jpauli — 2012-09-17T08:18:37+00:00 URL: https://externals.io/message/62903#63025 · In reply to: #63024 Roger captain :) I'll soon be on IRC to check this out and get used to PHP build tools and environment :) Julien.P > > > […] > > Hell yeah :) > > -- > Pierre > > @pierrejoye | http://blog.thepimp.net | http://www.libgd.org --- ## #63027 — Ferenc Kovacs — 2012-09-17T09:29:54+00:00 URL: https://externals.io/message/62903#63027 · In reply to: #63023 > > > […] > > A last bump on that. So nobody complained so far, I think Julien and > I can go ahead and start with 5.5 as soon as possible. > > Somehow, I've expected a bigger discussion about the election of the RMs. On a sidenote: it would be nice if we could have a wiki page/rfc about the process of the election, as currently we don't have one. Would be nice seeing what are the requirements, how are they elected(voting, how long should the poll be open, etc.), if there is a limit on the re-election, etc. I think that both David and Julien will be nice RMs, but doing this decision in this casual way somehow seems a little bit off for me., -- Ferenc Kovács @Tyr43l - http://tyrael.hu --- ## #63029 — jpauli — 2012-09-17T09:50:44+00:00 URL: https://externals.io/message/62903#63029 · In reply to: #63027 > > > > […] > Somehow, I've expected a bigger discussion about the election of the RMs. > On a sidenote: it would be nice if we could have a wiki page/rfc about the > process of the election, as currently we don't have one. > Would be nice seeing what are the requirements, how are they > elected(voting, how long should the poll be open, etc.), if there is a > limit on the re-election, etc. > I think that both David and Julien will be nice RMs, but doing this > decision in this casual way somehow seems a little bit off for me., +1, we even have nothing or little info about RMs into the wiki. I agree that must be taken care of. Julien.P --- ## #63030 — Pierre Joye — 2012-09-17T10:24:41+00:00 URL: https://externals.io/message/62903#63030 · In reply to: #63027 hi Ferenc, > Somehow, I've expected a bigger discussion about the election of the RMs. Right, but if only one team volunteers, there is no need of voting, except if there were objections to one of the members, but there is none :) > On a sidenote: it would be nice if we could have a wiki page/rfc about the > process of the election, as currently we don't have one. yes, well, pretty much the same than any other RFCs, a list of RMs pair instead of the usual RFC options (yes, no, or other). > Would be nice seeing what are the requirements, how are they > elected(voting, how long should the poll be open, etc.), Durations and co are fixed by the voting RFC already. > if there is a > limit on the re-election, etc. > I think that both David and Julien will be nice RMs, but doing this > decision in this casual way somehow seems a little bit off for me., Idea is to have one experimented RM with a new one. In this case, David and Julien. Once 5.5 is in the cruising mode, only Julien will remain (like only Stas will remain pretty soon as well). Feel free to create a page in the wiki for that. Cheers, -- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org --- ## #63032 — johannes@schlueters.de — 2012-09-17T14:44:33+00:00 URL: https://externals.io/message/62903#63032 · In reply to: #62903 Hi, > Let's keep things simple here, stay on topic and debate if we want to > start with 5.5 and who can RM it. I wonder if we really need two RMs. This two-RM-thing was introduced back when I was busy with different things at work, university, live, ... when Lukas stepped in to do some of the administrative tasks. Nowadays those administrative tasks are ruled way more in RFCs and the role of the RM, in my opinion, is more a task overseeing things (reviewing changes, reminding people about their "promises") etc. in the end those are all things *everybody* should be doing. For the remaining coordination though there should be a single person, who can judge on implications, when there is doubt. I'd therefore suggest that we go back to a single RM. This gives one person to talk to, which eases communication a lot (even if the single RM just delegates the issue back to some domain expert). A single RM, of course, has the risk to "disappear" due to changes in life or whatever but I don't think that's a major risk as the role might transition. Such a transition might also be good when selecting a successor - throw a successor on the prepared path after the .0 is done instead of throwing them directly in the center of the field a short time before a release where everybody tries to get his things in. David, I think you're experienced enough to fill this role alone. Thanks, johannes --- ## #63033 — Herman Radtke — 2012-09-17T14:57:47+00:00 URL: https://externals.io/message/62903#63033 · In reply to: #63032 > David, I think you're experienced enough to fill this role alone. One benefit to having two RM's is that Julien is learning from DSP. If there is a strong reason to have only one RM, then maybe we should consider a RM/vice-RM kind of pairing. -- Herman Radtke hermanradtke@gmail.com | http://hermanradtke.com --- ## #63034 — jpauli — 2012-09-17T15:05:20+00:00 URL: https://externals.io/message/62903#63034 · In reply to: #63033 > > […] > > > One benefit to having two RM's is that Julien is learning from DSP. If > there is a strong reason to have only one RM, then maybe we should consider > a RM/vice-RM kind of pairing. That's it, the idea has never been to have confusion, but help the new RM at well ... RMing. Getting used to tools and processes is not an easy task for the begining of RMing :-P Whoever is the new RM that said. Julien.P --- ## #63036 — johannes@schlueters.de — 2012-09-17T15:36:16+00:00 URL: https://externals.io/message/62903#63036 · In reply to: #63034 Hi, > > > […] > > That's it, the idea has never been to have confusion, but help the new > RM at well ... RMing. > Getting used to tools and processes is not an easy task for the > begining of RMing :-P Whoever is the new RM that said. There are very few special processes. In fact the only RM-specific things are around packaging the tarballs up, while that's described in an README. Besides that all processes affect everybody in the community and everybody should be aware of it. The RM simply is the last instance to identify/judge if things are unclear. the requirements for that are a) knowing the code quite well b) knowing whom to ask for a given issue. both things are good qualifications for *any* contributor. In my mail I also suggested to "train" a successor later in the game. Nowadays,thanks to all the RFCs and so on, the role of the RM is on the one hand very limited and on the other hand requires maing clear decisions. And well, two persons give two clear decisions or increase workload for themselves (due to extra coordination) and everybody else (for having two guys to follow) I don't mind if an RM has an "assistant" or "apprentice" or such, but I want a clear responsibility - I always describe the role as "the one who takes the blame." All the good stuff comes from the contributors, the RM is the one who in the end didn't catch the mistakes. johannes --- ## #63037 — Sebastian Bergmann — 2012-09-17T15:45:23+00:00 URL: https://externals.io/message/62903#63037 · In reply to: #63036 Am 17.09.2012 17:36, schrieb Johannes Schlüter: > There are very few special processes. In fact the only RM-specific > things are around packaging the tarballs up, while that's described in > an README. Does this have to be manual process? Is there something in it that cannot be described in a Makefile, build.xml, etc. instead? -- Sebastian Bergmann Co-Founder and Principal Consultant http://sebastian-bergmann.de/ http://thePHP.cc/ --- ## #63043 — johannes@schlueters.de — 2012-09-17T19:00:04+00:00 URL: https://externals.io/message/62903#63043 · In reply to: #63037 > Am 17.09.2012 17:36, schrieb Johannes Schlüter: > > […] > > Does this have to be manual process? Is there something in it that > cannot be described in a Makefile, build.xml, etc. instead? Even that would have to be triggered ;-) And well, then there are tasks which can't be automated, like writing a release announcement (human has to decide what's to be highlighted etc.) but well, there automation there is the less we need two guys doing that, the more you're confirming my point. johannes --- ## #63044 — David Soria Parra — 2012-09-17T22:00:47+00:00 URL: https://externals.io/message/62903#63044 · In reply to: #63037 > Am 17.09.2012 17:36, schrieb Johannes Schl?ter: > > […] > > Does this have to be manual process? Is there something in it that > cannot be described in a Makefile, build.xml, etc. instead? Yes, merging NEWS, writing news entries, mails and generating Changelog-5 (the issue is related to NEWS). Most of the rest can be automated so once a release hit .0 it's, as johannes pointed out, very straight forward --- ## #63045 — Pierre Joye — 2012-09-17T22:44:06+00:00 URL: https://externals.io/message/62903#63045 · In reply to: #63032 hi On Mon, Sep 17, 2012 at 4:44 PM, Johannes Schlüter wrote: > > I wonder if we really need two RMs. This two-RM-thing was introduced > back when I was busy with different things at work, university, > live, ... when Lukas stepped in to do some of the administrative tasks. Well, I have a totally different view on that period, and the issues were really not due to your activity at the university (or whatever else). And yes, not alone because of the 5.3 experience, I am totally convinced that we need a dual head RMs team. > David, I think you're experienced enough to fill this role alone. That's the point. And Julien will get it while working with David and the rest of the people involved in releases for the 1st months of 5.5. Then Julien will do 5.5 alone, or David alone (if they change their mind ;-). Cheers, -- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org --- ## #63046 — Pierre Joye — 2012-09-17T22:47:41+00:00 URL: https://externals.io/message/62903#63046 · In reply to: #63036 hi, On Mon, Sep 17, 2012 at 5:36 PM, Johannes Schlüter wrote: > There are very few special processes. In fact the only RM-specific > things are around packaging the tarballs up, while that's described in > an README. Besides that all processes affect everybody in the community > and everybody should be aware of it. The RM simply is the last instance > to identify/judge if things are unclear. the requirements for that are > a) knowing the code quite well b) knowing whom to ask for a given issue. > both things are good qualifications for *any* contributor. > > In my mail I also suggested to "train" a successor later in the game. > Nowadays,thanks to all the RFCs and so on, the role of the RM is on the > one hand very limited and on the other hand requires maing clear > decisions. And well, two persons give two clear decisions or increase > workload for themselves (due to extra coordination) and everybody else > (for having two guys to follow) That's where you see it wrong. There is only one team to follow, not two guys. The RMs have regular contacts, approve together important changes (aka no one liner or similar), etc. They are also more keen to get a better judgment than a single person (different views, etc.). There is no extra work load, only benefits. Also seeing what happened with the latest 5.3, I wonder if we should not have two again for 5.3 as well (kidding but.. ;-). Cheers, -- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org