Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:85405 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 58739 invoked from network); 22 Mar 2015 09:43:26 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 22 Mar 2015 09:43:26 -0000 Authentication-Results: pb1.pair.com smtp.mail=lester@lsces.co.uk; spf=permerror; sender-id=unknown Authentication-Results: pb1.pair.com header.from=lester@lsces.co.uk; sender-id=unknown Received-SPF: error (pb1.pair.com: domain lsces.co.uk from 217.147.176.214 cause and error) X-PHP-List-Original-Sender: lester@lsces.co.uk X-Host-Fingerprint: 217.147.176.214 mail4-2.serversure.net Linux 2.6 Received: from [217.147.176.214] ([217.147.176.214:36832] helo=mail4.serversure.net) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id E3/E7-00828-DBE8E055 for ; Sun, 22 Mar 2015 04:43:25 -0500 Received: (qmail 14949 invoked by uid 89); 22 Mar 2015 09:43:21 -0000 Received: by simscan 1.3.1 ppid: 14941, pid: 14945, t: 0.0839s scanners: attach: 1.3.1 clamav: 0.96/m:52/d:10677 Received: from unknown (HELO ?10.0.0.8?) (lester@rainbowdigitalmedia.org.uk@109.156.131.40) by mail4.serversure.net with ESMTPA; 22 Mar 2015 09:43:21 -0000 Message-ID: <550E8EB9.7070904@lsces.co.uk> Date: Sun, 22 Mar 2015 09:43:21 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: internals@lists.php.net References: In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Subject: =?UTF-8?B?UmU6IFtQSFAtREVWXSBUbyBSRkMgb3IgTm90IFRvIFJGQyBbd2FzIFI=?= =?UTF-8?B?ZTogW1BIUC1ERVZdIOWbnuWkje+8miBbUkZDXVtESVNDVVNTSU9OXSBBZGQgcHI=?= =?UTF-8?B?ZWdfcmVwbGFjZV9jYWxsYmFja19hcnJheSBmdW5jdGlvbl0=?= From: lester@lsces.co.uk (Lester Caine) On 22/03/15 08:54, Patrick Schaaf wrote: >> 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. While everything SHOULD be properly commented in the commit notes, isn't this just a matter of WHERE something is documented? If a bug is found and it's not got a record then a bug entry is raised and tagged in the commit log. That is where discussion takes place if there is something that needs discussing. If the bug fix goes beyond 'code behaviour fully inline with what's already documented' then it needs an RFC? I though that was already documented practice? 'Pure C level refactoring' is a grey area. Certainly the commit notes MUST have a reason justifying the change, but isn't this an area where refactoring may affect different builds in different ways? Again some means of hanging comments on a change would be useful, and the github tracker is not the place for that? So perhaps since it may actually introduce unseen bugs, it also needs a bug report? Even white space and style refactoring can be a pain at times when one is working through where a later regression originated? -- Lester Caine - G8HFL ----------------------------- Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk