Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:103926 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 22165 invoked from network); 31 Jan 2019 19:18:22 -0000 Received: from unknown (HELO mail-ot1-f51.google.com) (209.85.210.51) by pb1.pair.com with SMTP; 31 Jan 2019 19:18:22 -0000 Received: by mail-ot1-f51.google.com with SMTP id g16so3173973otg.11 for ; Thu, 31 Jan 2019 07:58:17 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=bRl2zvlpALEtA7c8loFn7zCDQsZKo32bm7lUMTdtty8=; b=bkTiS96PB5uZ4rwcsLiUAMcQaLPIFHNF5qXMYyn/fdg66hCvMBZLGYi2x6nni33fAa dWZhsWnFiLZhbzxGQ4WFlbztD26AWptsqryTw5XHsGhFwbvy5htaEmr3EQjNraU2MjQR vceRkqc2uEJm1vw1XVGJrzgBNxCGffwlOZllFLayIo5IWxVMUrNCjb7gDTSBt3Py3bv7 vYgIIBxE6eHH/16+BquS49VUQ1T72DNSXTZx1jfLcOvRXHgntmxvysRwDn/WYTrYbFtn 0+aQfBHF/a4SmSbC+xXLd2hW5K4QyecNN0+4So9bepO7Ojo9bYHfCptCcZsjNf684gbr sTdw== X-Gm-Message-State: AJcUukeT3H8rdaIB9ETBRtkNo7q5eORGD96bbpizs0IXD84grxa/Kxpb kAjQ3HIxPfmFPPqsNPXc+GzAtK06+1wVJqmrvRrQb9za X-Google-Smtp-Source: ALg8bN75STd+eQTZG5Nzce6nKd1DGY8aeRabD1umfvrpGagxiHFVG2wcte3R5K2JMaHT8gB7JtVx3kv10ZMrFcoTX3w= X-Received: by 2002:a9d:5c6:: with SMTP id 64mr26489439otd.274.1548950296645; Thu, 31 Jan 2019 07:58:16 -0800 (PST) MIME-Version: 1.0 References: <03f401d4b96b$18b9dc60$4a2d9520$@php.net> In-Reply-To: <03f401d4b96b$18b9dc60$4a2d9520$@php.net> Date: Thu, 31 Jan 2019 17:58:05 +0200 Message-ID: To: Zeev Suraski Cc: Internals Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Subject: Re: [PHP-DEV] RFC: RFC Workflow & Voting (2019 update) From: kalle@php.net (Kalle Sommer Nielsen) Hi Zeev Den tor. 31. jan. 2019 kl. 15.44 skrev Zeev Suraski : > > Without further ado, an RFC that=E2=80=99s attempting to comprehensively = solve many of the issues that have plagued our RFC process since it was has= tily introduced in 2011: > > > > https://wiki.php.net/rfc/voting2019 I wholeheartedly disagree with the PHP-FIG special exception to who can vote, call me biased but I do not believe it serves any purpose and is absurd. People who actively work on PHP, should be the ones to be able to have a choice, I think that should be reserved for any contributor who puts effort working on PHP. I do understand that we are the language and our work affects the others the most. However making special exceptions for who can vote and essentially having a say from an external source in what I in theory need to help maintain as a PHP Core Developer is terrible. Why not allow WordPress Core Developers to have a say instead, as their work has a larger impact on the usage of PHP? (That was obviously a bit of sarcasm, the last part). We are not allowed to vote at their individual projects features (nor do we need to have a say if we are not actively involved in the development of said projects or organizations) and I stand very strongly behind that belief. Besides this, it also creates uncertainty about who elects such, and simply should be dropped from the voting RFC as it was already fairly unclear from the original one. The contributors appendix also lists ChangeLog, SVN Migration etc, something to keep in mind if this RFC is moved forward to filter the list. Do I understand the PHP Packaging Decisions right that it requires to vote for a timeline for each version? I remember we have different opinions raised regarding the time to a new major version (should we have 7.4 vs go to 8.0, same for the 5 to 7 transition back then regarding a 5.7). This is the only issue I can think of and should be changed to requiring a vote if there is a dispute in regards to what the next version should be. As I don't really wanna vote just to vote for each of the minor versions of 8 once a year when its the most logical reason to go to 8.1 from 8.0, and so on until we reach the point where the next major is considerable. I think changes like the requiring a patch for RFCs is a very welcomed addi= tion. --=20 regards, Kalle Sommer Nielsen kalle@php.net