Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:98595 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 97468 invoked from network); 19 Mar 2017 23:11:54 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 19 Mar 2017 23:11:54 -0000 Authentication-Results: pb1.pair.com header.from=rowan.collins@gmail.com; sender-id=pass Authentication-Results: pb1.pair.com smtp.mail=rowan.collins@gmail.com; spf=pass; sender-id=pass Received-SPF: pass (pb1.pair.com: domain gmail.com designates 74.125.82.42 as permitted sender) X-PHP-List-Original-Sender: rowan.collins@gmail.com X-Host-Fingerprint: 74.125.82.42 mail-wm0-f42.google.com Received: from [74.125.82.42] ([74.125.82.42:35040] helo=mail-wm0-f42.google.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 2A/95-18522-8301FC85 for ; Sun, 19 Mar 2017 18:11:53 -0500 Received: by mail-wm0-f42.google.com with SMTP id u132so51330199wmg.0 for ; Sun, 19 Mar 2017 16:11:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding; bh=3cYAN9dqYFI2yqy+Tniz1XQDEvBuh9mE6WzrbsGvu0k=; b=bZuCgNJhWDNWTNfb24dEAzUp0m1uDCj26QciscP6tMLYale3Smq0AlYhlzR1a6kahZ VFO/5clgS7JqlqrnCou6CX2wKtSR7CnNszlHImrzBRCzKacv1OuAXkkNXdKW7NEAOiSR xdzHv9NGSEZD+ivEk2tml4UU1anVk+RffJIOYtpsCNy+CFE9zAReK8bLSAex/3YnETwQ meF1ZAIs4Fkt4iU8Fk3xmEOYwa2t6sAX7SPYIOuk+ZTObjhY1+dyjpGbwDvlcWDlpVES XesVg/vxTy19P6IBoatYIeTbOrZnzWG8JZSCidZJaRm+L5bp+ybaE4dGB4VYWLuJG/tB elmA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=3cYAN9dqYFI2yqy+Tniz1XQDEvBuh9mE6WzrbsGvu0k=; b=jOTw1okTcDgvv92qPvZ7CF0VKAb2LvW2bwpEvvZIt67t0oXOxSfKDwnribGOttPhzW eSTYDDxGV0g0kNwBW/D0K+wF3muQ+NQL7Bmy7JAzKmeNSdh5nxJdxQAh7EwQ6+mOOxAF ikPI7nC2xQy/DrdTiAGez0+uZ0aZY1UAsRrA67YEPaB/OemC1N0s/Tl+ZMYp6Nsin3mS N8M7vIdMga+NVTcUAivbUmUIFLcfM+IpzxlDCjKeOYsuaBQIdhOeHq9Qv52ZUvgOwVGc K/m+3udCC91AAy+7kEyAThCnFaTRLCbIc7jyHsF9wo6atj9/EJzDHng0n6Kt2DkuI16t pnVg== X-Gm-Message-State: AFeK/H0EuyPq3cQcCUaDWVUUqguTWUVEv4gnBvE8C/+a/KB8dI2DxEoJqPICxR6BYKlYeg== X-Received: by 10.28.174.203 with SMTP id x194mr7941014wme.85.1489965108676; Sun, 19 Mar 2017 16:11:48 -0700 (PDT) Received: from ?IPv6:2a00:23c4:4bd2:6e00:f9c4:f33d:cdac:90ad? ([2a00:23c4:4bd2:6e00:f9c4:f33d:cdac:90ad]) by smtp.googlemail.com with ESMTPSA id v14sm10756590wra.50.2017.03.19.16.11.47 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 19 Mar 2017 16:11:47 -0700 (PDT) To: PHP internals list References: <15fa63cb-6ca6-b809-20b8-5b0e2d357b29@gmx.de> <1304f0ec-2957-2fd0-070e-9f096e3fbb6a@gmail.com> <3aa0cb2a-4142-046e-d69f-b5481384099b@gmail.com> Message-ID: Date: Sun, 19 Mar 2017 23:11:45 +0000 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [PHP-DEV] Re: [RFC] Extended String Types For PDO From: rowan.collins@gmail.com (Rowan Collins) On 19/03/2017 21:54, Jakub Zelenka wrote: > I don't really think that we any definition for mantainer role. > Currently it varies depending on the extension. For example you won't > see many RFC's in date ext which is very well maintained by Derick and > most of the changes are decided by him which I think is a very good > thing and works very well. [...] > Sorry but I just don't agree with that. We are talking about a feature > for PDO that not many voters is interested in. That's completely > different than a language change. The interest in other core > extensions is often the same. Fair points. I'm not sure the RFC process as a whole works well for specialist decisions - the same has come up with very technical Engine changes. I think this kind of breaks down into two questions: - Which changes need an RFC? - If a change does need an RFC, what level of support does it need? I don't have particularly good answers, but "this change shouldn't have needed an RFC in the first place" is a very different direction from "after the RFC has been debated, this person should have a veto / casting vote". I realise that's not what you were suggesting, though, and I'm happy to go with "the current system is not really a problem". > If we had such rule on the minimal number of votes, one person could > easily block any progress on the any extension. I am a little curious what you meant by this, though; I can't see how it follows at all. Regards, -- Rowan Collins [IMSoP]