Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:78332 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 80619 invoked from network); 26 Oct 2014 00:03:46 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 26 Oct 2014 00:03:46 -0000 Authentication-Results: pb1.pair.com smtp.mail=johannes@schlueters.de; spf=permerror; sender-id=unknown Authentication-Results: pb1.pair.com header.from=johannes@schlueters.de; sender-id=unknown Received-SPF: error (pb1.pair.com: domain schlueters.de from 217.114.215.10 cause and error) X-PHP-List-Original-Sender: johannes@schlueters.de X-Host-Fingerprint: 217.114.215.10 mail.experimentalworks.net Received: from [217.114.215.10] ([217.114.215.10:60413] helo=mail.experimentalworks.net) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id F1/C5-36207-06A3C445 for ; Sat, 25 Oct 2014 20:03:45 -0400 Received: by mail.experimentalworks.net (Postfix, from userid 1003) id C773646ADA; Sun, 26 Oct 2014 02:03:57 +0200 (CEST) X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on km31408.keymachine.de X-Spam-Level: X-Spam-Status: No, score=-1.0 required=3.0 tests=ALL_TRUSTED autolearn=unavailable version=3.3.2 X-Spam-HAM-Report: * -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP Received: from [192.168.2.34] (ppp-93-104-2-217.dynamic.mnet-online.de [93.104.2.217]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: johannes@schlueters.de) by mail.experimentalworks.net (Postfix) with ESMTPSA id 4EBE84590F; Sun, 26 Oct 2014 02:03:54 +0200 (CEST) Message-ID: <1414281815.3228.35.camel@kuechenschabe> To: Joe Watkins Cc: Stas Malyshev , Weinand Bob , Derick Rethans , Pierre Joye , PHP Developers Mailing List Date: Sun, 26 Oct 2014 02:03:35 +0200 In-Reply-To: <1414268667.2624.118.camel@localhost.localdomain> References: <1414217636.2624.89.camel@localhost.localdomain> <1414229963.2624.103.camel@localhost.localdomain> <544BE9FE.3030603@sugarcrm.com> <1414268667.2624.118.camel@localhost.localdomain> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.10.4-0ubuntu2 Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Subject: Re: [PHP-DEV] PHPDBG nonsense (Was: Re: [PHP-CVS] com php-src: Made phpdbg compatible with new engine: ...) From: johannes@schlueters.de (Johannes =?ISO-8859-1?Q?Schl=FCter?=) disclaimer: I'm not overly interested in phpdbg, maybe I should be, but for the moment I'm not. On Sat, 2014-10-25 at 21:24 +0100, Joe Watkins wrote: > I'd like to everyone to stay grounded in reality and say that we have > been checking code into php-src for months, very very few people have > expressed an interest in what we were actually doing, you aren't one of > them Stas. The observation that very few people comment on your commits is correct, the conclusion unfortunately isn't. The thing is: only very few people are actively reviewing commits at all. Of those few only few look deeper into commits ... unfortunately we don't have a good review rate. As long as tests pass barely anybody complains about when things change. This is not phpdbg specific but is true for most parts of PHP, on the engine we have a few eyes, and a few extension maintainers have highlighting filters on commits touching their extensions, but that's a minority. This partly comes from people assuming that bigger changes will be announced on internals, probably even with RFC. Even though there are people who want an RFC&vote for everything I'd give extension (and sapi) maintainers some freedom ... but the line is a tough one ... The other reason is that reading commits is tough and requires a lot of time ... I have no idea how to give incentives to do more review but we desperately need that (again: not phpdbg specific but for the full project) one approach to solve that would be to require reviews (either in a Linux-like way with maintainers pulling changes and signing them off, taking responsibility that way, or in a tool-based way like Android with gerrit or such requiring reviews before a change is actually pushed into the repo) to push any changes but then again our project is too small and in some areas we can be happy to have somebody working on bugfixes at all ... enforcing reviews there will slow us down and add quite some process cost ... maybe somebody finds a good way ... johannes