Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:85399
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain bof.de designates 80.242.145.70 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CAPwsocE8uzEZNaMxTZSwGyRmofaPFc1SSXv2yrYbK+KK9TaVWQ@mail.gmail.com>
References: <CAPg3XxKG3g=Oh79+_woyBedyP2CFkWPFLKnNuCuX6nTn0f6GKA@mail.gmail.com>
	<CAPwsocGiGMS0GT9jERMNRboe_nC=sGZjYWFr=AhmOGP0WncJrQ@mail.gmail.com>
	<CAJ26g5RmUhBWW0+oPMvL_kp5gE7E173YUtDm-tV8BiV=F1u_6A@mail.gmail.com>
	<CAPwsocE8uzEZNaMxTZSwGyRmofaPFc1SSXv2yrYbK+KK9TaVWQ@mail.gmail.com>
Date: Sun, 22 Mar 2015 09:54:45 +0100
Message-ID: <CAJ26g5S4UVC1QmD0Mq7toW1vjwj-5U3twd01QChXwwKppddu7A@mail.gmail.com>
To: Leigh <leight@gmail.com>
Cc: internals <internals@lists.php.net>, Peter Cowburn <petercowburn@gmail.com>
Content-Type: multipart/alternative; boundary=001a114907747e69a50511dcb3ad
Subject: =?UTF-8?B?UmU6IFtQSFAtREVWXSBUbyBSRkMgb3IgTm90IFRvIFJGQyBbd2FzIFJlOiBbUEhQLURFVg==?=
	=?UTF-8?B?XSDlm57lpI3vvJogW1JGQ11bRElTQ1VTU0lPTl0gQWRkIHByZWdfcmVwbGFjZV9jYWxsYmFja19hcnJh?=
	=?UTF-8?B?eSBmdW5jdGlvbl0=?=
From: php@bof.de (Patrick Schaaf)

--001a114907747e69a50511dcb3ad
Content-Type: text/plain; charset=UTF-8

Am 22.03.2015 09:45 schrieb "Leigh" <leight@gmail.com>:
>
> On 22 March 2015 at 07:00, Patrick Schaaf <php@bof.de> wrote:
>>
>> Hmm. Is that really the line to be drawn? An RFC, by itself, provides a
good point to spell out a change clearly, and anchor it for reference in
discussion. Discussion on internals itself cannot provide that, it is too
scattered, and POC code provides it at the code layer only. Thinking about
documentation, for example.
>
> Sure, I can agree on RFC all the things.

Probably not all things, but surely everything visible at the language
level, that would need documentation. Syntax, functions, function argument
changes. Probably also changes of official C level API for module authors
(thinking about session management, ZPP, etc).

Pure C level refactoring - probably not. And not for bugfixing that brings
code behaviour fully inline with what's already documented.

>> So, maybe the line is better drawn at what needs a vote, and what does
not?
>>
>> Just an idea: as soon as an RFC goes up / leaves draft state, could it
have a "needs a vote?" prevoting section? And if a certain minimum opts for
"needs a vote" (within a minimum discussion period after leaving draft),
one must be held? (thinking about a one week period and three or five
needs-a-vote calls, or something similar)
>
> I suppose this could be part of the discussion on list when it is not
obvious, then we at least have some documented opinions on the decision,
rather than the assumptions of individuals.

Okay, that's easier to implement and probably sufficient,  if everybody
play nice. Or, another idea and maybe a lot less work to implement: all
active release managers could have a "want a vote" button on pending RFC
pages.

Patrick

--001a114907747e69a50511dcb3ad--