Re: What's our official stance on small self-contained additions in a micro version

On Wed, Apr 1, 2015 at 6:28 PM, François Laupretre <francois@php.net> wrote: > > De : Ferenc Kovacs [mailto:tyra3l@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. > I see your point, but the consensus/status quo(based on past mailing list discussion and( is/was that not everything requires an RFC. > > 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. > again, I'm fine with changing the current status quo, but we can't pretend that this was always the consensus when we were doing otherwise and >95% of the people seemed to be okay with it (I had a couple of threads in the past years where I tried to clarify a couple of things about the voting and releaseprocess rfcs, but nothing really come out of it). > > 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. > As I mentioned this wasn't something without precedence, but seeing how Derick(ext/date lead author/maintainer) was explicitly against this change, and there were no favorable response from the list I tend to agree with the revert. For the record this was merged by Stas: http://git.php.net/?p=php-src.git;a=commitdiff;h=cc2fd00942d59975326166be70cd36da85a681d3 -- Ferenc Kovács @Tyr43l - http://tyrael.hu