On Jan 28, 2013, at 2:14 PM, Anthony Ferrara ircmax...@gmail.com wrote:
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
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
hi,
On Mon, Jan 28, 2013 at 8:14 PM, Anthony Ferrara ircmax...@gmail.com wrote:
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
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
On Mon, Jan 28, 2013 at 12:53 PM, Zeev Suraski z...@zend.com wrote:
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
-Original Message-
From: Levi Morrison [mailto:morrison.l...@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 voting
On Mon, Jan 28, 2013 at 12:53 PM, Zeev Suraski z...@zend.com wrote
On Mon, Jan 28, 2013 at 8:14 PM, Anthony Ferrara ircmax...@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
On Mon, 28 Jan 2013, Anthony Ferrara wrote:
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
2013/1/28 Zeev Suraski z...@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
2013/1/28 Derick Rethans der...@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
On Mon, Jan 28, 2013 at 11:11 PM, Patrick ALLAERT patrickalla...@php.netwrote:
2013/1/28 Zeev Suraski z...@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
On Mon, Jan 28, 2013 at 10:24 PM, Ferenc Kovacs tyr...@gmail.com wrote:
On Mon, Jan 28, 2013 at 11:11 PM, Patrick ALLAERT patrickalla...@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
12 matches
Mail list logo
