Anatol, On Sat, Aug 22, 2015 at 10:34 AM, Anatol Belski <anatol....@belski.net> wrote: > Hi Anthony, > >> -----Original Message----- >> From: Anthony Ferrara [mailto:ircmax...@gmail.com] >> Sent: Saturday, August 22, 2015 4:44 AM >> To: Pierre Joye <pierre....@gmail.com> >> Cc: Anatol Belski <anatol....@belski.net>; Scott Arciszewski >> <sc...@paragonie.com>; Niklas Keller <m...@kelunik.com>; Trevor Suarez >> <ric...@gmail.com>; PHP internals <internals@lists.php.net> >> Subject: Re: [PHP-DEV] Recap - Core functions throwing exceptions in PHP7 >> >> Pierre >> >> On Aug 21, 2015 22:33, "Pierre Joye" <pierre....@gmail.com> wrote: >> > >> > On Sat, Aug 22, 2015 at 9:16 AM, Anthony Ferrara <ircmax...@gmail.com> >> wrote: >> > >> > > If that's what it will take I will happily draft one tomorrow morning. >> But >> > > if the RMs are against it, I will respect that as well. Hence the >> dilemma. >> > >> > For what I understand the RMs are not against what it is proposed but >> > its incompleteness and the fact that it affects the timeline for php >> > 7. >> > >> > The sooner will benefit from a RFC, making this whole discussion a lot >> > clearer. The latter is a requirement to change, even slightly, >> > anything about what we decided for php 7. The RMs role is to ensure we >> > respect what we decided by RFC, hence the oppositions. >> >> By convention, it is also to decide which rfcs are applicable for a specific >> release. >> I would like to respect that. If they say no, I won't waste time and energy >> on the >> rfc process as it will be pointless as it won't affect 7.0. If they say yes, >> then we >> can make it quick and as painless as possible and settle it once and for all. >> >> It bothers me though that it has to come down to this. But that's another >> discussion for another day. >> > Thanks for your constructive responses and deferential conduct. > > Looking retrospectively t the RFC votes closing days noted in the wiki > > - engine exceptions on March 8th > - CSPRNG on March 28th > - Throwable on June 17th > > the engine exceptions and CSPRNG lay quite near in time, so it is obvious > CSPRNG implementation couldn't have been changed short before or after the > other one as they cross each other so close in time. A notable fact also is > that quite a new stuff in Throwable was taken already after release circle > start and the point of no accept for the new RFCs. In any case, by the times > so much of new functionality was clearly overmuch to digest. And it is still > even more of discovery for people not having PHP7 experiences. > > For what it matters, a suggestion about a need on a strategy with this matter > sounded in the early days of this discussion. Unfortunately it was not taken > seriously, which is sad as well. The exact goal of calling for RFC already at > that time was to bring all the bike shedding onto a productive path and to > avoid a situation like it is now. Actually this argument is nothing else than > bike shedding on the times and mindsets, so were not worth to mention. But > having not the 1.5 month time lost, we probably wouldn't stand where we stand > now. > > From what all the bike shedding crystalized, there are at least three main > directions to see, when it comes to throw in functions. Please correct me > when I'm wrong > > - security aspect (this discussion) > - conversion of fatal errors (touched partially in a PR by Aaron) > - ZPP handling (mentioned by Nikita) > > These look like they can be handled separately, what they have in common is > > - definition of Error and Exception use case > - further development of the exception hierarchy > > Please don't catch me on the above, it is only what could be marked by my > mind from the discussions. > > From these, either there can be an RFC with a proper solution of one or all > the topics spliced with the possible delay of the PHP7 final awareness, or > there can be an RFC to include a partial solution being pushed so far and > possible inconsistency consequences, or CSPRNG functionality can be deferred > until a complete solution, or CSPRNG can be reimplemented as class where > exceptions belong to the natural flow, or a good sustainable solution can be > offered in 7.1. Any other ideas. From the time line - there are five release > slots until final yet. Were it an RFC which is accepted, the change would > land in RC3 most likely, that would mean there were yet three release slots > till final. Under the condition that the current timeline is held. > > From the last stand point discussed with the other RMs, as they seem not to > be reachable for a direct discussion most of today - such a change affects > long term features and language paradigm, which is the matter of the > community competence. There's the 7.0 timeline which is a voted thing, there > is a release process document which defines that the votes take place on RFCs > directly and not on the mailing lists. The RMs belief is that the suggested > change is the exact kind of needing a collective decision. Due to the > concerns explained earlier, the timeline RFC and other items seem to be in > clash with the change how it is proposed ATM. To undo/change any of those > items to pass the suggested change in, another RFC seems to be inevitable. > With the hope that the cautions expressed were taken into account it's up to > everyone to take actions and make a choice they hold for right. > > Anthony, sincere thanks for your activity and open minded handling in this > affair.
>From what it sounds like, you wouldn't be opposed to an RFC for getting it into 7.0. Is that what I understood? If so, we'll have something in draft today. Thanks for the clarity! Anthony -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
