Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:65304
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.223.171 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CAAyV7nEWFMqBhKE-Q=MquMANmWp+p27Dn-X7nA5ocWRDHshEKA@mail.gmail.com>
References: <CAAyV7nEWFMqBhKE-Q=MquMANmWp+p27Dn-X7nA5ocWRDHshEKA@mail.gmail.com>
Date: Mon, 28 Jan 2013 22:25:27 +0100
Message-ID: <CAH-PCH4vi84LTKqR8mO4Xp1sme5VuJh3Rt3PUG7DjnOZHvyDkQ@mail.gmail.com>
To: Anthony Ferrara <ircmaxell@gmail.com>
Cc: "internals@lists.php.net" <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=f46d04462dd478236004d45fea9f
Subject: Re: [PHP-DEV] Purpose of voting
From: tyra3l@gmail.com (Ferenc Kovacs)

--f46d04462dd478236004d45fea9f
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Mon, Jan 28, 2013 at 8:14 PM, Anthony Ferrara <ircmaxell@gmail.com>wrote=
:

> Hey all,
>
> After reading the Voting Periods email thread, I'm left wondering a simpl=
e
> 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 implementati=
on
> in C, but are fine with the PHP details).
>
> I'll leave out my opinion (and justification) for now, I'm curious what y=
ou
> 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:

   1. 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 so=
me
   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 anot=
her
   vote before merging ofc,).
   2. 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.

--=20
Ferenc Kov=C3=A1cs
@Tyr43l - http://tyrael.hu

--f46d04462dd478236004d45fea9f--