Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:94657
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain daveyshafik.com from 209.85.220.182 cause and error)
MIME-Version: 1.0
Sender: me@daveyshafik.com
In-Reply-To: <4b53c180-40bf-7b11-6d6f-2d68eee7cf54@gmail.com>
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> <4b53c180-40bf-7b11-6d6f-2d68eee7cf54@gmail.com>
Date: Sat, 23 Jul 2016 13:44:15 -0700
Message-ID: <CANaX5nehCTXsO3Vg5Zsipn8Dx0gmGo=9XB0SJ79KKt-w172MNw@mail.gmail.com>
To: Stanislav Malyshev <smalyshev@gmail.com>
Cc: Yasuo Ohgaki <yohgaki@ohgaki.net>, Derick Rethans <derick@php.net>, 
	"internals@lists.php.net" <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=94eb2c048e444ff49c0538539d40
Subject: Re: [PHP-DEV] Re: [RFC][VOTE] Session ID without hashing
From: davey@php.net (Davey Shafik)

--94eb2c048e444ff49c0538539d40
Content-Type: text/plain; charset=UTF-8

Stas,

The issue is that changes were made once the voting started, and some of us
were waiting for the vote to restart:

> I'd like to see the vote re-run (1 week?) with the changes in place. I
didn't vote because I expected it to be restarted. I would have voted -1 on
the current proposal.

Changing the RFC during voting requires a _restart_ not an extension. The
vote must be re-run. I will not put this in 7.1 without a new vote.

- Davey

On Sat, Jul 23, 2016 at 12:50 PM, Stanislav Malyshev <smalyshev@gmail.com>
wrote:

> 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
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>

--94eb2c048e444ff49c0538539d40--