On Mon, Jun 13, 2016 at 4:32 PM, Joe Watkins <pthre...@pthreads.org> wrote:
> Afternoon internals, > > > Is there a roadmap somewhere that describes this, or any background > discussion of doing this within the 7.x series, rather than planning for > 8.0? > > We have no such sensible thing as a plan :) > > The reason for the existence of PHP 7 (ng) is efficiency of the kind I > described, this is surely well understood by everyone. > > What may not be well understood is that the job is nothing like complete. > Vigilant observers will have noticed that Dmitry does indeed have a JIT for > NG, which is very useful research, but it sucks so hard that we can't > deploy it. > > The reason for this is that, in part, generated code doesn't look so much > different to code executed by the VM, though details differ considerably; > It needs to do at least the same job, it may need to do more (because of > guarding and other boring things). > > Without knowing anything about generating instructions anyone can tell > that a complicated Zend, with all kinds of edge cases and inconsistencies > (specifically regarding ZE) is going to necessitate the generation of > complicated code, to accommodate those edge cases and inconsistencies. > > A lot of effort is being put in to finding and resolving inconsistencies > in the engine such as this, a lot of effort has been expended and will be > expended on 7 in the pursuit of efficiency. A lot of this is of no > consequence to BC. > > You can count the number of people putting in the majority of this effort > on your fingers ... erecting a road block in front of them in the name of > unobtainable BC is harmful to the apparent goals of the project at this > time. > > The kinds of changes that must be delayed until 8.0 are surely going to be > proposed, and we will surely delay them by consensus. > > > This is my main concern, also > > I will update the RFC, if Dmitry doesn't, when voting is closed. > > I will ensure the change is properly documented in the manual also. > > > Ideally, this could lead to a revised policy > > I think our policy has always been to consider each proposal on a > case-by-case basis. That's all I have done, and all I am suggesting others > do. > > I know it's very strange to hear someone talking about "goals" ... > > We can waste a bunch of time trying to define them, voting on them, and so > on ... or, we can look at what is going on, and what has gone on, and come > to sensible conclusions. > > Cheers > Joe > > > On the other hand lack of release process and constant BC breaks also hindered the adoption of past PHP versions. With 7.0 we were in a good spot as we were able to package the BC breaks with major performance improvements which makes it attractive for people to upgrade(and still, with a successful 7.0 release we voted to delay the eol date for 5.6). While I don't want to impede progress we have to be careful about BC breaks, and especially when from the outside it can be seen as some people are above the rules/processes while others get gated by it. >From the user POV I really liked what we were doing in the past: mark stuff first with E_DEPRECATED and then remove the feature later on. I think that our main problem is that we don't have a roadmap for major versions and historically our major release cycle was pretty slow (4.0.0: 2000, 5.0.0: 2004, 5.3 was basically a major version in 2009 and 7.0.0: 2015 dec), so now that a major just shipped people will try to squeeze in BC breaks regardless of our release process (and yes, it doesn't not help that the releaseprocess rfc was lacking clear definitions on some terms). As I mentioned before I don't wanna impede progress so not trying to block this specific rfc seeing how well the votes went, but I think it would be useful for the future governance if we could: 1, update/expand our releaseprocess rfc so that it reflects the actual/desired process and can spare us from the bureaucracy and word twisting to suite one's current position. 2, figure out how can we do BC breaks in a more timely manner (either via changing the releaseprocess, reclassifying what BC break means or having more frequent major versions). -- Ferenc Kovács @Tyr43l - http://tyrael.hu
