Hey: On Tue, Oct 13, 2015 at 6:12 AM, Anatol Belski <anatol....@belski.net> wrote:
> > > > -----Original Message----- > > From: Nikita Popov [mailto:nikita....@gmail.com] > > Sent: Monday, October 12, 2015 10:33 PM > > To: Anatol Belski <anatol....@belski.net> > > Cc: Dmitry Stogov <dmi...@zend.com>; PHP internals < > internals@lists.php.net> > > Subject: Re: [PHP-DEV] Re: Forbid rebinding scope of closures created by > > ReflectionFunctionAbstract::getClosure() > > > > On Mon, Oct 12, 2015 at 10:22 PM, Anatol Belski <anatol....@belski.net> > > wrote: > > > > > Hi, > > > > > > > -----Original Message----- > > > > From: Nikita Popov [mailto:nikita....@gmail.com] > > > > Sent: Monday, October 12, 2015 8:57 PM > > > > To: Dmitry Stogov <dmi...@zend.com> > > > > Cc: PHP internals <internals@lists.php.net>; Andrea Faulds > > > > <a...@ajf.me>; > > > Stas > > > > Malyshev <smalys...@sugarcrm.com>; Bob Weinand <bwo...@php.net>; > > > > Anatol Belski <anatol....@belski.net> > > > > Subject: [PHP-DEV] Re: Forbid rebinding scope of closures created by > > > > ReflectionFunctionAbstract::getClosure() > > > > > > > > > It would be great, if we stop any commits into PHP-7.0 except for > > > > critical fixes now > > > > > > > > Maybe keep PHP-7.0 open (or as open as release branches usually > > > > are), > > > but from > > > > now on only cherry-pick critical fixes into PHP-7.0.0 (instead of > > > > merging everything)? > > > > > > > I commit myself to Dmitry's words. What matters today and especially > > > after > > > RC5 is the stability. Today we should invest into testing and bug > > > fixes more than into improvements (aka fixes to something that is not > > > broken). It really matters for the quality of the final. That's the > > > message to convey probably. > > > > > > > To rephrase my question: Should we treat PHP-7.0 the same way we treat > > PHP-5.6 and other release branches (i.e. all kinds of bug fixes are > okay, even if > > it's just improving a test or fixing some inconsequential behavior), or > do you > > want to limit the PHP-7.0 branch to actually critical fixes now? From > what you > > say, I assume the former rather than the latter? > > > Talking about "critical" I meant usual definitions as something that > causes memory corruptions, data loss, big functional impact, security > flaws, etc. > agree, bugs > > The tricky point with 7.0 right now is that it's a lot of new stuff with > very high expectations standing short before final. Coupling this with the > "critical" from above, the definition I would make were - it is a) critical > and b) can be fixed properly and cannot wait until after the final release. > The dev time spent to fix something after 7.0 final is indeed lost for the > 7.0 final. Any new code short before final increases the instability risk > of the final. > > Fe small functional regressions are probably not always critical. If a > (even small) functional regression breaks a lot, it is critical. If a > functional regression breaks a rare use case - it is not critical. If > improving a test helps to cover some critical code - so yes, it is critical > as well. Anything that is critical can involve anything you've mentioned > like adding tests or code. > hmm, I understand your ideas, but I think maybe we should forbid such things as well for this moment, because it make things complicated to judge(if it is critical or not), such things can goes to 7.1 let's only allows bugs fix (as you mentioned above) to be committed into PHP-7.0 before the final release of its thanks > > Hopefully I could express myself better now. Cherry-pick is of course a > solution, but IMHO it is important every dev to understand the unique > situation we currently have to face. It is better to avoid cherry-picking > in favor of the "mission aware" code :) > Regards > > Anatol > > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > -- Xinchen Hui @Laruence http://www.laruence.com/
