Hey:
Hey:
On Fri, Mar 20, 2015 at 7:53 PM, Alain Williams addw@phcomp.co.uk
wrote:Hi internals,
Hi internals,
The RFC to add a user-land function for an easy-to-use and reliable
preg_replace_callback_array()in PHP is up for discussion:
https://wiki.php.net/rfc/preg_replace_callback_arrayThis proposes adding one function:
preg_replace_callback_array()
that
is the better way to Implement when there are multiple patterns
need to
replace.I would love to hear your feedback! :)
Any objections?I’ve sent this mail for four days, I don’t know if this RFC needs a
vote.
If you guys have no objections on this, please review the code and
merge it,
thanks.Nice job, i like the idea.
I am not sure about a RFC or not. It somehow looks like a sane
replacement for something we killed (with good reasons).Let see what the other think :)
I used s/something/code/ge in a perl script that I wrote a few days
ago. Very
useful. It would have been a lot more work to do it another way.So: +1 to the ability to do this, regardless of what mechanism is
eventually chosen.I also +1 for this.
if there is no objections raises, I am going to merge it tomorrow..
mergedthanks
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?..
thanks
--
Alain Williams
Linux/GNU Consultant - Mail systems, Web sites, Networking, Programmer,
IT Lecturer.
+44 (0) 787 668 0256 http://www.phcomp.co.uk/
Parliament Hill Computers Ltd. Registration Information:
http://www.phcomp.co.uk/contact.php
#include <std_disclaimer.h>--
--
Xinchen Hui
@Laruence
http://www.laruence.com/--
Xinchen Hui
@Laruence
http://www.laruence.com/
Hey:
Hey:
On Fri, Mar 20, 2015 at 7:53 PM, Alain Williams addw@phcomp.co.uk
wrote:On Fri, Mar 20, 2015 at 7:03 PM, Wei Dai zxcvdavid@gmail.com
wrote:Hi internals,
Hi internals,
The RFC to add a user-land function for an easy-to-use and
reliable
preg_replace_callback_array()in PHP is up for discussion:
https://wiki.php.net/rfc/preg_replace_callback_arrayThis proposes adding one function:
preg_replace_callback_array()
that
is the better way to Implement when there are multiple patterns
need to
replace.I would love to hear your feedback! :)
Any objections?I’ve sent this mail for four days, I don’t know if this RFC needs a
vote.
If you guys have no objections on this, please review the code and
merge it,
thanks.Nice job, i like the idea.
I am not sure about a RFC or not. It somehow looks like a sane
replacement for something we killed (with good reasons).Let see what the other think :)
I used s/something/code/ge in a perl script that I wrote a few days
ago. Very
useful. It would have been a lot more work to do it another way.So: +1 to the ability to do this, regardless of what mechanism is
eventually chosen.I also +1 for this.
if there is no objections raises, I am going to merge it tomorrow..
mergedthanks
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.
Am 22.03.2015 02:30 schrieb "Leigh" leight@gmail.com:
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
Am 22.03.2015 02:30 schrieb "Leigh" leight@gmail.com:
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)
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.
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.
Am 22.03.2015 09:45 schrieb "Leigh" leight@gmail.com:
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.
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.
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.
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
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.
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.
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
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.
The minimal discussion time is well documented and approved. Same for the
voting period.