Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:61804 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 37557 invoked from network); 26 Jul 2012 06:52:16 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 26 Jul 2012 06:52:16 -0000 Authentication-Results: pb1.pair.com smtp.mail=smalyshev@sugarcrm.com; spf=pass; sender-id=pass Authentication-Results: pb1.pair.com header.from=smalyshev@sugarcrm.com; sender-id=pass Received-SPF: pass (pb1.pair.com: domain sugarcrm.com designates 67.192.241.123 as permitted sender) X-PHP-List-Original-Sender: smalyshev@sugarcrm.com X-Host-Fingerprint: 67.192.241.123 smtp123.dfw.emailsrvr.com Linux 2.6 Received: from [67.192.241.123] ([67.192.241.123:44087] helo=smtp123.dfw.emailsrvr.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id D1/81-19570-E19E0105 for ; Thu, 26 Jul 2012 02:52:14 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp2.relay.dfw1a.emailsrvr.com (SMTP Server) with ESMTP id 37B687830E for ; Thu, 26 Jul 2012 02:52:11 -0400 (EDT) X-Virus-Scanned: OK Received: by smtp2.relay.dfw1a.emailsrvr.com (Authenticated sender: smalyshev-AT-sugarcrm.com) with ESMTPSA id DF3E6782CD for ; Thu, 26 Jul 2012 02:52:10 -0400 (EDT) Message-ID: <5010E919.501@sugarcrm.com> Date: Wed, 25 Jul 2012 23:52:09 -0700 Organization: SugarCRM User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: "internals@lists.php.net" References: <50105BFC.80900@ajf.me> <50109D18.3000305@rotorised.com> In-Reply-To: <50109D18.3000305@rotorised.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [PHP-DEV] RFCs and organisation From: smalyshev@sugarcrm.com (Stas Malyshev) Hi! >> Secondly, I noticed that Python's PEPs are numbered, unlike PHP's >> RFCs. Whilst they aren't quite the same thing, I wonder if this would >> be useful, particularly since it provides a simple and unambiguous way >> to refer to one, e.g. RFC 123 instead of "RFC on how to write an RFC". Why have numbers if we can use URLs? URLs both uniquely identify the RFC and suggest what they are about. Can you say what PEP 410 is about? How about https://wiki.php.net/rfc/releaseprocess? > If we do that, we should call them PHP RFCs (PRFCs?) instead, to avoid > confusion with IETF RFCs, otherwise it may get confusing. I have yet to meet one person who was confused when we talked about generators RFC and thought we meant IETF RFC describing standards for electrical generators in data centers. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227