Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:91866
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.217.176 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CAKws9z2rR9Vg-6B5FitnxEUuws4Hys9sQ61GjrkqPsE2mT03Ug@mail.gmail.com>
References: <CAKws9z0ahvvd8z=Y5nSH8EmZPgA-6VMmOMsrc-SZSaPGb28Y-g@mail.gmail.com>
	<CAH-PCH7Tz601+=ML+HQ4S0hG_Vi5aFZfnULY=1v4pwVTc16o7A@mail.gmail.com>
	<CAKws9z2rR9Vg-6B5FitnxEUuws4Hys9sQ61GjrkqPsE2mT03Ug@mail.gmail.com>
Date: Tue, 22 Mar 2016 20:27:19 +0100
Message-ID: <CAH-PCH7kz+1ZWXJ19mCAeEDgBRc+jmitNayDR_A67AGPYCgAnw@mail.gmail.com>
To: Scott Arciszewski <scott@paragonie.com>
Cc: PHP Internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=001a1135e3b2aaa714052ea83371
Subject: Re: [PHP-DEV] [RFC][VOTE] Deprecate then Remove Mcrypt Closed (23-6)
From: tyra3l@gmail.com (Ferenc Kovacs)

--001a1135e3b2aaa714052ea83371
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Tue, Mar 22, 2016 at 7:09 PM, Scott Arciszewski <scott@paragonie.com>
wrote:

> On Tue, Mar 22, 2016 at 1:41 PM, Ferenc Kovacs <tyra3l@gmail.com> wrote:
>
>>
>>
>> On Tue, Mar 22, 2016 at 6:00 PM, Scott Arciszewski <scott@paragonie.com>
>> wrote:
>>
>>> Hi all,
>>>
>>> https://wiki.php.net/rfc/mcrypt-viking-funeral
>>>
>>> The tally of closing (2016-03-22T17:00:00) is 23 Yes, 6 No. This is a
>>> 79.3%
>>> favorable response, which exceeds the 2/3 majority by a significant
>>> margin.
>>>
>>> Thanks to everyone who voted or participated in this discussion.
>>>
>>> I've heard and respect some of the objections raised by folks who voted
>>> No,
>>> but moving this liability out of the core into PECL as soon as possible
>>> is
>>> not only a good move for the security of PHP applications, but now we
>>> know
>>> it's the choice the community wants.
>>>
>>> As promised, I'll get the E_DEPRECATED patch written soon.
>>>
>>> Additionally, I will have a decrypt-only mcrypt polyfill project writte=
n
>>> hopefully before 7.1.0-alpha but definitely before 7.1.0. This will all=
ow
>>> people to migrate towards something better, e.g.
>>> openssl_encrypt()/openssl_decrypt().
>>>
>>> Scott Arciszewski
>>> Chief Development Officer
>>> Paragon Initiative Enterprises <https://paragonie.com>
>>>
>>
>> You ignored the voting process and my headsup mail about it, and also
>> ignored most of the feedback from the replies.
>>
>>
>> --
>> Ferenc Kov=C3=A1cs
>> @Tyr43l - http://tyrael.hu
>>
>
> =E2=80=8BLet's go line by line, then?
>
> 1. Email internals@lists.php.net to measure reaction to your intended
> proposal.
>
> 2. Get wiki RFC karma
>
> Already had that.
> =E2=80=8B
> =E2=80=8B3. =E2=80=8BCreate the RFC
>
> Yes, obviously, I did that. :)
>
> 4. When your RFC is ready for discussion:
>
> * Change the status of your RFC page to =E2=80=9CUnder Discussion=E2=80=
=9D
>
> Check.
>
> * Change its section on https://wiki.php.net/RFC to =E2=80=9CUnder Discus=
sion=E2=80=9D
>
> Totally fair to cry foul on this one; I did not do this. I wasn't aware o=
f
> this step, otherwise I would have.
> * Send email to internals@lists.php.net introducing your RFC.
>
> I did this two months ago.
>

As I mentioned in my mail in the voting thread I couldn't find any email
from you to the list with the link to the rfc, still waiting for your reply
to show me that mail.


>
> 5. Listen to the feedback, and try to answer/resolve all questions.
>
> =E2=80=8BThere were no substantial questions that needed to be addressed/=
resolved.
> People expressed concerns, but if we blocked every RFC because someome ha=
s
> a concern that doesn't form a substantive question, would we ever get
> anything done?
>

It was brought up that the rfc should be clear about what it is targeting,
voting shouldn't happen without an explicit target version, as we have
different rules and expectations for a minor than a major version.
For the record our release process rfc sucks a bit in this regard(
https://wiki.php.net/rfc/releaseprocess), because it states that BC breaks
shouldn't happen in a minor version, but it explicitly allows moving exts
from core to pecl even though that this could cause userland impact (for
example ext is moved to pecl then some internal API is changed in the core
(which can also happen in a minor version) and the pecl extension doesn't
receive an update so pecl install won't work out of the box). This means
that technically you can target both 7.2 or 8.0 with your rfc for moving
mcrypt to pecl but people would vote differently depending of what version
do you pick for the rfc to target.


>
> 6. When discussion ends, and a minimum period of two weeks has passed
> since you mailed internals@lists.php.net in step 4, then you can move
> your RFC to =E2=80=9CVoting=E2=80=9D status.
>
> Two months >=3D two weeks.
>

see above, nobody seen your rfc page or commented on it before you linked
it from your voting thread. Heck, as far as I can tell, it wasn't even
listed on https://wiki.php.net/rfc before you put it up for voting.
For the record I would probably vote yes for this proposal regardless of
your answers on the feedback, I just want to have the process followed
properly.

--=20
Ferenc Kov=C3=A1cs
@Tyr43l - http://tyrael.hu

--001a1135e3b2aaa714052ea83371--