> On 01 04 2015, at 18:28, François Laupretre <franc...@php.net> wrote: > >> De : Ferenc Kovacs [mailto:tyr...@gmail.com] >> >> I could accept any decision between holding off new features until next >> minor/major and allowing features explicitly without going through an RFC, >> but I >> want to have an explicit definition on what is allowed and how should the >> case- >> by-case process work. > > The release process document is clear : "New features or additions to the > core should go through the RFC process." (hopefully considering the 'core' as > the whole PHP distribution). It would be better using "must" instead of > "should" but it is quite clear. > > So, providing "a room for exceptions on a case by case basis and only for > small self-contained features and additions" does not mean that these > features don't have to go through an RFC. There is nothing to add to the > rules, we just need to have them enforced by people who currently merge new > features without demanding an approved RFC. If everyone respects the rules, > the 'case by case process' is clear, it means 'approved through an RFC'. Only > bug fixes with no side effect can be merged without an RFC. > > So, once again, as https://github.com/php/php-src/pull/1145 clearly did not > follow the rules and was not approved in any way, I'm asking whoever merged > it to revert the change and ask the author to go through an RFC.
It’s not a secret that I’m not a big fan of too much bureaucracy, we’re still humans that can discuss and argue without a formal RFC. If anything develops to be controversial, let’s go through an RFC, if not, then fine and let them go ahead. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
