Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:94655
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.218.42 as permitted sender)
To: Yasuo Ohgaki <yohgaki@ohgaki.net>, Derick Rethans <derick@php.net>
References: <CAGa2bXaSkozJLLtycujwmHyas9TofRw5s6JzG0EQQvPyU0pxNQ@mail.gmail.com>
 <CAGa2bXYLuxq2Yywr_v4B5ExQ37bWE9Fc45KLNCcXVQS3d47_kA@mail.gmail.com>
 <alpine.DEB.2.20.1607121124450.16349@whisky.home.derickrethans.nl>
 <CAGa2bXYF7y6ZefKqaxVkdmYtXpoZPU3doAguOC_recGrQ4Fr2Q@mail.gmail.com>
 <86246bad-5290-8ad7-be48-1d981d720182@gmail.com>
Cc: "internals@lists.php.net" <internals@lists.php.net>
Message-ID: <4b53c180-40bf-7b11-6d6f-2d68eee7cf54@gmail.com>
Date: Sat, 23 Jul 2016 12:50:14 -0700
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:45.0)
 Gecko/20100101 Thunderbird/45.2.0
MIME-Version: 1.0
In-Reply-To: <86246bad-5290-8ad7-be48-1d981d720182@gmail.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] Re: [RFC][VOTE] Session ID without hashing
From: smalyshev@gmail.com (Stanislav Malyshev)

Hi!

> We already had a vote, at it was completed. Having another vote on the
> same subject, slightly modified, is highly irregular and contrary to
> voting RFC, which mandates 6 month period or *substantial* changes (with
> assumed new discussion period I imagine, since past discussion can't
> really count for substantially changed proposal) to schedule a new vote
> on a rejected proposal.
> 
> This also gives pretty bad example - on failed vote, tweak a little
> issue and issue immediate revote, repeat until one of the votes
> succeeds. I understand that this is not at all your intent here, but
> it's the pattern that we do not want to enable.
> 
> I voted yes for it, and it is a pity that it failed, as it seems,
> because of a miscommunication (maybe not, I don't know), but going
> against our own agreed process I think is not a good outcome either.

Oops, I thought I was talking about another RFC vote that failed. Sorry
for the confusion. This one seems to have succeeded. This is weirder
case then... I'd say just implement the uncontroversial part then and
submit the controversial part as a new RFC?

-- 
Stas Malyshev
smalyshev@gmail.com