Hey all,
After reading the Voting Periods email thread, I'm left wondering a simple
question (which has a difficult answer):
What should we be voting on when voting on an RFC: on the RFC proposed
feature, or on the patch itself?
I've always approached it as we're voting for the concept (and details)
provided in the RFC. But it appears that other people have been voting on
the specifics of the attached patch (so theoretically an RFC could be
rejected entirely because some people don't like part of the implementation
in C, but are fine with the PHP details).
I'll leave out my opinion (and justification) for now, I'm curious what you
all think...
Thoughts?
Anthony
Hey all,
After reading the Voting Periods email thread, I'm left wondering a simple
question (which has a difficult answer):What should we be voting on when voting on an RFC: on the RFC proposed
feature, or on the patch itself?
Personally, I'm discussing/voting on the feature. We do tend to combine our discussions, but voting seems to be directly for the proposed feature. I don't necessarily disagree with this approach, as we tend to hash out the implementation during the discussions. It might save RFC authors a lot of time and keyboard taps if we discussed/voted on a feature prior to discussing implementation. This could open the door for a flood of feature requests in the form of RFCs, but I don't believe that would happen.
One of the advantages of combining the patch(es) with an RFC is it shows the author has put forth an effort in thinking the idea through. That said, a "rule of thumb" (or official rule) that RFC authors should provide a patch once the feature has been approved might work.
In the end, separating the two would end up saving the RFC's author and this list time as to whether a feature should be considered. However, there are times where the implementation could change the outcome of the feature vote itself.
I've always approached it as we're voting for the concept (and details)
provided in the RFC. But it appears that other people have been voting on
the specifics of the attached patch (so theoretically an RFC could be
rejected entirely because some people don't like part of the implementation
in C, but are fine with the PHP details).I'll leave out my opinion (and justification) for now, I'm curious what you
all think...Thoughts?
Anthony
Hi!
What should we be voting on when voting on an RFC: on the RFC proposed
feature, or on the patch itself?
Either, or both, depending on the RFC and the intent of the author. Note
that since there's rarely competing teams/patches on the same feature,
accepting the RFC means also accepting the approach proposed by the team
doing it, otherwise it's meaningless - if we accept the idea, but not
implementation, what the use would be for the idea which has nobody to
implement it?
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
hi,
Hey all,
After reading the Voting Periods email thread, I'm left wondering a simple
question (which has a difficult answer):What should we be voting on when voting on an RFC: on the RFC proposed
feature, or on the patch itself?I've always approached it as we're voting for the concept (and details)
provided in the RFC. But it appears that other people have been voting on
the specifics of the attached patch (so theoretically an RFC could be
rejected entirely because some people don't like part of the implementation
in C, but are fine with the PHP details).I'll leave out my opinion (and justification) for now, I'm curious what you
all think...Thoughts?
We do not vote on RFC for features/change without patch(es).
However I could imagine a kind of poll to see if a complex feature is
worse the effort to implement it. It can be very frustrated and
demotivating to spend literally days on something that will be
rejected.
Cheers,
Pierre
@pierrejoye | http://blog.thepimp.net | http://www.libgd.org
What should we be voting on when voting on an RFC: on the RFC proposed
feature, or on the patch itself?
I think it should be exclusively on the concept. We never vote about code
changes anywhere - including when we refactor existing parts. Why would
we vote about the implementation here?
The concept is the important part, not the implementation.
Zeev
What should we be voting on when voting on an RFC: on the RFC proposed
feature, or on the patch itself?I think it should be exclusively on the concept. We never vote about code
changes anywhere - including when we refactor existing parts. Why would
we vote about the implementation here?The concept is the important part, not the implementation.
Implementation can be a HUGE factor in whether I vote yes or no.
-----Original Message-----
From: Levi Morrison [mailto:morrison.levi@gmail.com]
Sent: Monday, January 28, 2013 10:04 PM
To: Zeev Suraski
Cc: Anthony Ferrara; internals@lists.php.net
Subject: Re: [PHP-DEV] Purpose of votingWhat should we be voting on when voting on an RFC: on the RFC
proposed feature, or on the patch itself?I think it should be exclusively on the concept. We never vote about
code changes anywhere - including when we refactor existing parts.
Why would we vote about the implementation here?The concept is the important part, not the implementation.
Implementation can be a HUGE factor in whether I vote yes or no.
Fair enough, it has next to zero effect on mine - unless we're dealing
with something extremely fundamental. Otherwise, why not put each and
every commit up for a vote?
Zeev
2013/1/28 Zeev Suraski zeev@zend.com:
What should we be voting on when voting on an RFC: on the RFC proposed
feature, or on the patch itself?I think it should be exclusively on the concept. We never vote about code
changes anywhere - including when we refactor existing parts. Why would
we vote about the implementation here?
Just to +1 Zeev's opinion here.
It's perfectly valid to accept an RFC and comment on the
implementation on what should be improved or what sucks in it.
If one is voting "no" mostly because of the implementation, then I
would say that there is a lack of information in the voting process
when saying "no". (No why... ?)
Side node: whatever the formal "process" we will use we will always
have to be flexible enough to listen to each other and not falling
into bureaucracy too much.
Patrick
On Mon, Jan 28, 2013 at 11:11 PM, Patrick ALLAERT patrickallaert@php.netwrote:
2013/1/28 Zeev Suraski zeev@zend.com:
What should we be voting on when voting on an RFC: on the RFC proposed
feature, or on the patch itself?I think it should be exclusively on the concept. We never vote about
code
changes anywhere - including when we refactor existing parts. Why would
we vote about the implementation here?Just to +1 Zeev's opinion here.
It's perfectly valid to accept an RFC and comment on the
implementation on what should be improved or what sucks in it.If one is voting "no" mostly because of the implementation, then I
would say that there is a lack of information in the voting process
when saying "no". (No why... ?)Side node: whatever the formal "process" we will use we will always
have to be flexible enough to listen to each other and not falling
into bureaucracy too much.Patrick
voting no based on the implementation would be that bad if the more voters
could participate in the discussion phase, as that is where those problems
should be laid out and addressed.
as Client also said, knowing why a person voted no is much easier to bear
for the author even if he doesn't agree with those.
--
Ferenc Kovács
@Tyr43l - http://tyrael.hu
On Mon, Jan 28, 2013 at 11:11 PM, Patrick ALLAERT <patrickallaert@php.net
wrote:
It's perfectly valid to accept an RFC and comment on the
implementation on what should be improved or what sucks in it.If one is voting "no" mostly because of the implementation, then I
would say that there is a lack of information in the voting process
when saying "no". (No why... ?)voting no based on the implementation would be that bad if the more voters
could participate in the discussion phase, as that is where those problems
should be laid out and addressed.
as Client also said, knowing why a person voted no is much easier to bear
for the author even if he doesn't agree with those.
In this particular case, a lot of people felt that the concept itself was
undesirable. Particularly memorable was the crass flaming of Stas.
Also I think the approach of defining specifics while the general concept
was under question, was misguided to say the least. Feedback was ignored or
forewarned because it didn't fit in the narrow cast you provided.
People voting "no" based on the implementation were the least of your
worries.
Arpad
On Mon, Jan 28, 2013 at 8:14 PM, Anthony Ferrara ircmaxell@gmail.comwrote:
Hey all,
After reading the Voting Periods email thread, I'm left wondering a simple
question (which has a difficult answer):What should we be voting on when voting on an RFC: on the RFC proposed
feature, or on the patch itself?I've always approached it as we're voting for the concept (and details)
provided in the RFC. But it appears that other people have been voting on
the specifics of the attached patch (so theoretically an RFC could be
rejected entirely because some people don't like part of the implementation
in C, but are fine with the PHP details).I'll leave out my opinion (and justification) for now, I'm curious what you
all think...Thoughts?
Anthony
what I've seen this far is if an rfc includes a patch accepting the rfc
means that we accept the patch to be merged.
usually that also means that the change will be introduced into the lowest
possible version where appropriate (eg, now 5.3 is in basically critical
bugfix/security fixes only mode, or how much of a BC break is the proposed
change, etc.).
I think that in some cases having a vote without an impelentation could be
useful.
I see two common scenarios:
- voting before a major task where are multiple options are present
(should we use utf-8 or utf-16 internally for the unicode support for
example, the RFC would show the pros and cons, some benchmarks, maybe some
POC, but not a full fledged implementation because nobody would dare to
cook that up until he/she feels that it is backed by a majority of the
voters(it can still fail on the implementation and it would require another
vote before merging ofc,). - voting where the implementation doesn't really an issue, but we want
to get the common vision/agreement about some change (should we drop
support of archaic/less used platform/compiler/etc.).
I also think that listing the potential BC break of an RFC and the
suggested target version should a mandatory part of every RFC.
I'm almost sure that the accessor RFC would have won over the votes if it
would have explicitly targeted the next after 5.5 version (or if it could
have reached the current status like 2-3 months ago).
Just my 2 cents of course.
--
Ferenc Kovács
@Tyr43l - http://tyrael.hu
I've always approached it as we're voting for the concept (and details)
provided in the RFC. But it appears that other people have been voting on
the specifics of the attached patch (so theoretically an RFC could be
rejected entirely because some people don't like part of the implementation
in C, but are fine with the PHP details).I'll leave out my opinion (and justification) for now, I'm curious what you
all think...Thoughts?
Both the idea and implementation needs to be sound. If not, I vote "no"
(and that also means "no" when it makes APC's life harder).
cheers,
Derick
2013/1/28 Derick Rethans derick@php.net:
Both the idea and implementation needs to be sound. If not, I vote "no"
(and that also means "no" when it makes APC's life harder).
This is a bit unfair. APC is just one byte code caching mechanism out
there, even if it's the mostly used or most performing one (and even
the one I prefer by far).
If it was part of the core, then it would make more sense voting this way.
--
Patrick