Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:107190 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 11753 invoked from network); 17 Sep 2019 14:55:38 -0000 Received: from unknown (HELO php-smtp3.php.net) (208.43.231.12) by pb1.pair.com with SMTP; 17 Sep 2019 14:55:38 -0000 Received: from php-smtp3.php.net (localhost [127.0.0.1]) by php-smtp3.php.net (Postfix) with ESMTP id 2320A2C0479 for ; Tue, 17 Sep 2019 05:32:47 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on php-smtp3.php.net X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,RCVD_IN_DNSWL_LOW,SPF_HELO_PASS,URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.2 X-Spam-ASN: AS11403 64.147.123.0/24 X-Spam-Virus: No Received: from wout4-smtp.messagingengine.com (wout4-smtp.messagingengine.com [64.147.123.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by php-smtp3.php.net (Postfix) with ESMTPS for ; Tue, 17 Sep 2019 05:32:46 -0700 (PDT) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.west.internal (Postfix) with ESMTP id 97A635B3 for ; Tue, 17 Sep 2019 08:32:45 -0400 (EDT) Received: from imap26 ([10.202.2.76]) by compute7.internal (MEProxy); Tue, 17 Sep 2019 08:32:45 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; bh=tp/8Qf I55ZeLBYywPrEgNSj6GHeFcXztjvrl8C/u7mA=; b=T9+XsXG+ntb4BvjyHoD48r TUFSzJ+gwRArDDFCxWWtTS89utsBO8NZtUZw2HWFkeSJ4aAV5WEw0UaglbI9SuCQ bZ9ikTv2L3gUoVcuD2B8CMnBzsoYKRDRK1GCIF+NQNm994eJxKQs8DjjbQoZ9XeL zWDAHa7zcbwoP2SPPqLrqnijjCCgkVjnnFPv7w6dXivxfiCc2mU041SttD33bDbq EePN5w5lwHtvGIpthvBD7aE1vK2HAvAHVVp37da2jrBcXmrLImScKP4tzWJl03RX 0+gBtgeiPMwCLxn8iUnGrZfDmWYM65RcZAryBRPLeX3Uq6jzZPdnIT6idWpy7Zyw == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedufedrudeigddvjecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefofgggkfgjfhffhffvufgtsehttdertderredtnecuhfhrohhmpedfnfgrrhhr hicuifgrrhhfihgvlhgufdcuoehlrghrrhihsehgrghrfhhivghlughtvggthhdrtghomh eqnecurfgrrhgrmhepmhgrihhlfhhrohhmpehlrghrrhihsehgrghrfhhivghlughtvggt hhdrtghomhenucevlhhushhtvghrufhiiigvpedt X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id DC54914200A1; Tue, 17 Sep 2019 08:32:44 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.1.7-237-gf35468d-fmstable-20190912v1 Mime-Version: 1.0 Message-ID: <4f3978bc-a362-4424-a8aa-7258794e5c8b@www.fastmail.com> In-Reply-To: <6067334c-b327-9ad7-aff3-11f3208813ee@gmail.com> References: <6067334c-b327-9ad7-aff3-11f3208813ee@gmail.com> Date: Tue, 17 Sep 2019 07:32:24 -0500 To: "php internals" Content-Type: text/plain X-Envelope-From: Subject: Re: [PHP-DEV] Defining the PHP Group From: larry@garfieldtech.com ("Larry Garfield") On Mon, Sep 16, 2019, at 6:56 PM, Stanislav Malyshev wrote: > Hi! > > > For there to be a veto, of the kind that anyone can actually use, it must > > be established somewhere. > > And that's what I am concerned about. Once we start assuming the RFC > process is not for solving technical questions for everything, we get > into this kind of rule lawyering and nitpicking into the texts which > never were intended to be able to serve as something that can work while > being base for rule-lawyering and nitpicking. It's not a constitution > (not that lawyers don't find all kinds of things all the time there that > were never written there either) and the fact that voting RFC or > whatever document is on wiki now does or does not have certain words in > there does not have any sacred meaning, because it wasn't even meant for > that. These are utilitarian documents which were written for specific > purposes, and should be understood within that context. And if they do > not match what we want to do now, they can and should be changed. > > -- > Stas Malyshev > smalyshev@gmail.com Simple question for those that keep arguing that the RFC process is only applicable to a certain subset of issues: OK, so what's the alternative? If we wanted to make a structural or governance change to PHP, what is the process? If we really did feel there was a reason to make a fundamental change to the language (whatever that means), what is the process? If we wanted to change the RFC process, what is the process? If we don't have those, and want to set them up, what is the process for defining the process? --Larry Garfield