# To RFC or Not To RFC [was Re: 回复： [RFC][DISCUSSION] Add preg_replace_callback_array function] - Thread: https://externals.io/message/85361 - Original archive: https://news-web.php.net/php.internals/85361 - Started by Peter Cowburn on 2015-03-21T12:30:31+00:00 - Messages: 9 - Reply by email to internals@lists.php.net - More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt --- ## #85361 — Peter Cowburn — 2015-03-21T12:30:31+00:00 URL: https://externals.io/message/85361#85361 > Hey: > > > > […] > wrote: > > […] > that > > […] > need to > > […] > vote. > > […] > merge it, > > […] > ago. Very > > […] > eventually chosen. > > […] > merged > > thanks > Whoa, hold on there a second. An RFC was created, presumably intending to follow that line of procedure. Then Xinchen comes along and puts a middle finger up to the whole process, reverts back to the old "if no-one complains by tomorrow, merge it" approach, then does the merge. I'm all for avoiding the potentially unnecessary red tape of the RFC process. Particularly for small, standalone changes like this. I fear there are other who aren't so lenient. Thoughts?.. > > […] > IT Lecturer. > > […] > http://www.phcomp.co.uk/contact.php > > […] > > > > -- > Xinchen Hui > @Laruence > http://www.laruence.com/ --- ## #85389 — Leigh — 2015-03-22T01:30:35+00:00 URL: https://externals.io/message/85361#85389 · In reply to: #85361 > > > > […] > wrote: > > […] > reliable > > […] > > > > Whoa, hold on there a second. > > An RFC was created, presumably intending to follow that line of procedure. > Then Xinchen comes along and puts a middle finger up to the whole process, > reverts back to the old "if no-one complains by tomorrow, merge it" > approach, then does the merge. > > I'm all for avoiding the potentially unnecessary red tape of the RFC > process. Particularly for small, standalone changes like this. I fear there > are other who aren't so lenient. > > Thoughts?.. > Yep, this does look like another case of simply ignoring rules. The fact that what does and does not require an RFC does not help, this probably didn't need one, however one was created and the rules need to be stuck to. Instead of forcing this change to be reverted, because it really is self-contained, we need a succinct wiki document on what does and doesn't require an RFC. --- ## #85393 — Patrick Schaaf — 2015-03-22T07:00:55+00:00 URL: https://externals.io/message/85361#85393 · In reply to: #85389 Am 22.03.2015 02:30 schrieb "Leigh" : > > Yep, this does look like another case of simply ignoring rules. The fact > that what does and does not require an RFC does not help, this probably > didn't need one, however one was created and the rules need to be stuck to. Hmm. Is that really the line to be drawn? An RFC, by itself, provides a good point to spell out a change clearly, and anchor it for reference in discussion. Discussion on internals itself cannot provide that, it is too scattered, and POC code provides it at the code layer only. Thinking about documentation, for example. So, maybe the line is better drawn at what needs a vote, and what does not? Just an idea: as soon as an RFC goes up / leaves draft state, could it have a "needs a vote?" prevoting section? And if a certain minimum opts for "needs a vote" (within a minimum discussion period after leaving draft), one must be held? (thinking about a one week period and three or five needs-a-vote calls, or something similar) Patrick --- ## #85394 — Pierre Joye — 2015-03-22T07:05:31+00:00 URL: https://externals.io/message/85361#85394 · In reply to: #85393 > > Am 22.03.2015 02:30 schrieb "Leigh" : > > […] > to. > > Hmm. Is that really the line to be drawn? An RFC, by itself, provides a > good point to spell out a change clearly, and anchor it for reference in > discussion. Discussion on internals itself cannot provide that, it is too > scattered, and POC code provides it at the code layer only. Thinking about > documentation, for example. > > So, maybe the line is better drawn at what needs a vote, and what does not? > > Just an idea: as soon as an RFC goes up / leaves draft state, could it have > a "needs a vote?" prevoting section? And if a certain minimum opts for > "needs a vote" (within a minimum discussion period after leaving draft), > one must be held? (thinking about a one week period and three or five > needs-a-vote calls, or something similar) I would not say it better :) RFC, even for small things streamline everything and make it easy to get the idea and write docs. However the main problem here is to ask on Friday and apply on Saturday. --- ## #85398 — Leigh — 2015-03-22T08:45:37+00:00 URL: https://externals.io/message/85361#85398 · In reply to: #85393 > > Hmm. Is that really the line to be drawn? An RFC, by itself, provides a > good point to spell out a change clearly, and anchor it for reference in > discussion. Discussion on internals itself cannot provide that, it is too > scattered, and POC code provides it at the code layer only. Thinking about > documentation, for example. > Sure, I can agree on RFC all the things. > So, maybe the line is better drawn at what needs a vote, and what does not? > > Just an idea: as soon as an RFC goes up / leaves draft state, could it > have a "needs a vote?" prevoting section? And if a certain minimum opts for > "needs a vote" (within a minimum discussion period after leaving draft), > one must be held? (thinking about a one week period and three or five > needs-a-vote calls, or something similar) > I suppose this could be part of the discussion on list when it is not obvious, then we at least have some documented opinions on the decision, rather than the assumptions of individuals. --- ## #85399 — Patrick Schaaf — 2015-03-22T08:54:45+00:00 URL: https://externals.io/message/85361#85399 · In reply to: #85398 Am 22.03.2015 09:45 schrieb "Leigh" : > > > > […] good point to spell out a change clearly, and anchor it for reference in discussion. Discussion on internals itself cannot provide that, it is too scattered, and POC code provides it at the code layer only. Thinking about documentation, for example. > > Sure, I can agree on RFC all the things. Probably not all things, but surely everything visible at the language level, that would need documentation. Syntax, functions, function argument changes. Probably also changes of official C level API for module authors (thinking about session management, ZPP, etc). Pure C level refactoring - probably not. And not for bugfixing that brings code behaviour fully inline with what's already documented. > > […] not? > > […] have a "needs a vote?" prevoting section? And if a certain minimum opts for "needs a vote" (within a minimum discussion period after leaving draft), one must be held? (thinking about a one week period and three or five needs-a-vote calls, or something similar) > > I suppose this could be part of the discussion on list when it is not obvious, then we at least have some documented opinions on the decision, rather than the assumptions of individuals. Okay, that's easier to implement and probably sufficient, if everybody play nice. Or, another idea and maybe a lot less work to implement: all active release managers could have a "want a vote" button on pending RFC pages. Patrick --- ## #85401 — Leigh — 2015-03-22T08:57:01+00:00 URL: https://externals.io/message/85361#85401 · In reply to: #85399 > > Okay, that's easier to implement and probably sufficient, if everybody > play nice. Or, another idea and maybe a lot less work to implement: all > active release managers could have a "want a vote" button on pending RFC > pages. > +1 on RM sign-off for immediate merge, or requesting a vote first. --- ## #85402 — Pierre Joye — 2015-03-22T09:05:28+00:00 URL: https://externals.io/message/85361#85402 · In reply to: #85398 > > > > […] too > > […] about > > […] > Sure, I can agree on RFC all the things. > > > […] not? > > […] for > > […] > I suppose this could be part of the discussion on list when it is not > obvious, then we at least have some documented opinions on the decision, > rather than the assumptions of individuals. The minimal discussion time is well documented and approved. Same for the voting period. --- ## #85405 — Lester Caine — 2015-03-22T09:43:21+00:00 URL: https://externals.io/message/85361#85405 · In reply to: #85399 > > […] > Probably not all things, but surely everything visible at the language > level, that would need documentation. Syntax, functions, function argument > changes. Probably also changes of official C level API for module authors > (thinking about session management, ZPP, etc). > > Pure C level refactoring - probably not. And not for bugfixing that brings > code behaviour fully inline with what's already documented. While everything SHOULD be properly commented in the commit notes, isn't this just a matter of WHERE something is documented? If a bug is found and it's not got a record then a bug entry is raised and tagged in the commit log. That is where discussion takes place if there is something that needs discussing. If the bug fix goes beyond 'code behaviour fully inline with what's already documented' then it needs an RFC? I though that was already documented practice? 'Pure C level refactoring' is a grey area. Certainly the commit notes MUST have a reason justifying the change, but isn't this an area where refactoring may affect different builds in different ways? Again some means of hanging comments on a change would be useful, and the github tracker is not the place for that? So perhaps since it may actually introduce unseen bugs, it also needs a bug report? Even white space and style refactoring can be a pain at times when one is working through where a later regression originated? -- Lester Caine - G8HFL ----------------------------- Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk