On Mon, Jan 28, 2013 at 10:24 PM, Ferenc Kovacs wrote:
> On Mon, Jan 28, 2013 at 11:11 PM, Patrick ALLAERT >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 i
On Mon, Jan 28, 2013 at 11:11 PM, Patrick ALLAERT wrote:
> 2013/1/28 Zeev Suraski :
> >> 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 any
2013/1/28 Derick Rethans :
> 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 e
2013/1/28 Zeev Suraski :
>> 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
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
On Mon, Jan 28, 2013 at 8:14 PM, Anthony Ferrara 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 patch itself?
> -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
On Mon, Jan 28, 2013 at 12:53 PM, Zeev Suraski 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 existin
> 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?
Th
hi,
On Mon, Jan 28, 2013 at 8:14 PM, Anthony Ferrara 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 patch it
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 th
On Jan 28, 2013, at 2:14 PM, Anthony Ferrara 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 patch itself?
12 matches
Mail list logo
