Everything

php

To RFC or Not To RFC [was Re: 回复： [RFC][DISCUSSION] Add preg_replace_callback_array function]

php.internals

Peter Cowburn

11 years ago

On 21 March 2015 at 08:14, Xinchen Hui <laruence@php.net> wrote:

> Hey:
>
> On Fri, Mar 20, 2015 at 9:14 PM, Xinchen Hui <laruence@php.net> wrote:
> > Hey:
> >
> > On Fri, Mar 20, 2015 at 7:53 PM, Alain Williams <addw@phcomp.co.uk>
> wrote:
> >> On Fri, Mar 20, 2015 at 10:46:58PM +1100, Pierre Joye 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_array
> >>> >>
> >>> >> This 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..
> 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?..

Leigh

11 years ago

On 21 March 2015 at 12:30, Peter Cowburn <petercowburn@gmail.com> wrote:

> On 21 March 2015 at 08:14, Xinchen Hui <laruence@php.net> wrote:
>
> > Hey:
> >
> > On Fri, Mar 20, 2015 at 9:14 PM, Xinchen Hui <laruence@php.net> wrote:
> > > Hey:
> > >
> > > On Fri, Mar 20, 2015 at 7:53 PM, Alain Williams <addw@phcomp.co.uk>
> > wrote:
> > >> On Fri, Mar 20, 2015 at 10:46:58PM +1100, Pierre Joye 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_array
> > >>> >>
> > >>> >> This 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..
> > 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?..
>

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.

Patrick Schaaf

11 years ago

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

Pierre Joye

11 years ago

On Mar 22, 2015 2:01 PM, "Patrick Schaaf" <php@bof.de> wrote:

>
> 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.

Leigh

11 years ago

On 22 March 2015 at 07:00, Patrick Schaaf <php@bof.de> wrote:

>
> 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.

Patrick Schaaf

11 years ago

Am 22.03.2015 09:45 schrieb "Leigh" <leight@gmail.com>:

>
> On 22 March 2015 at 07:00, Patrick Schaaf <php@bof.de> wrote:
>>
>> 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

Leigh

11 years ago

On 22 March 2015 at 08:54, Patrick Schaaf <php@bof.de> wrote:

>
> 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.

Lester Caine

11 years ago

On 22/03/15 08:54, Patrick Schaaf wrote:

>> 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

Pierre Joye

11 years ago

On Mar 22, 2015 3:45 PM, "Leigh" <leight@gmail.com> wrote:

>
> On 22 March 2015 at 07:00, Patrick Schaaf <php@bof.de> wrote:
> >
> > 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.