Hi, On Wed, Apr 1, 2015 at 6:15 PM, Michael Wallner <m...@php.net> wrote:
> > > 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. > > I agree here. I think that we should definitely email to the internals about any small addition (self-contained constant or function) and if there are no objection and everyone agrees that it's a good idea, then I don't think we need RFC. Cheers Jakub
