Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:78330 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 68458 invoked from network); 25 Oct 2014 18:20:53 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 25 Oct 2014 18:20:53 -0000 Authentication-Results: pb1.pair.com smtp.mail=smalyshev@sugarcrm.com; spf=pass; sender-id=pass Authentication-Results: pb1.pair.com header.from=smalyshev@sugarcrm.com; sender-id=pass Received-SPF: pass (pb1.pair.com: domain sugarcrm.com designates 108.166.43.99 as permitted sender) X-PHP-List-Original-Sender: smalyshev@sugarcrm.com X-Host-Fingerprint: 108.166.43.99 smtp99.ord1c.emailsrvr.com Linux 2.6 Received: from [108.166.43.99] ([108.166.43.99:43193] helo=smtp99.ord1c.emailsrvr.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 4E/A4-36207-20AEB445 for ; Sat, 25 Oct 2014 14:20:52 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp21.relay.ord1c.emailsrvr.com (SMTP Server) with ESMTP id 20F753809E3; Sat, 25 Oct 2014 14:20:48 -0400 (EDT) X-Virus-Scanned: OK Received: by smtp21.relay.ord1c.emailsrvr.com (Authenticated sender: smalyshev-AT-sugarcrm.com) with ESMTPSA id 7064E380956; Sat, 25 Oct 2014 14:20:47 -0400 (EDT) X-Sender-Id: smalyshev@sugarcrm.com Received: from Stass-MacBook-Pro.local (108-66-6-48.lightspeed.sntcca.sbcglobal.net [108.66.6.48]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA) by 0.0.0.0:465 (trex/5.3.2); Sat, 25 Oct 2014 18:20:48 GMT Message-ID: <544BE9FE.3030603@sugarcrm.com> Date: Sat, 25 Oct 2014 11:20:46 -0700 Organization: SugarCRM User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: Weinand Bob , Derick Rethans , Pierre Joye CC: Joe Watkins , PHP Developers Mailing List References: <1414217636.2624.89.camel@localhost.localdomain> <1414229963.2624.103.camel@localhost.localdomain> In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Subject: Re: [PHP-DEV] PHPDBG nonsense (Was: Re: [PHP-CVS] com php-src: Made phpdbg compatible with new engine: ...) From: smalyshev@sugarcrm.com (Stas Malyshev) Hi! > Just a minor question, Derick. If you care about phpdbg, why are you > only dropping any comment about it by the time it got into php-src > repo? It’s known that all the development currently (except for > master, but that just was a merge and then a pure rewrite on top of > that merge, nothing related to the protocol) is going on in > krakjoe/phpdbg github repo. There was now an xml-protocol branch for > three weeks before it got merged into krakjoe/phpdbg#master. You had > vast time to notice it and complain before, if you’d really have > cared. I would like to weigh in here. If we're talking about things in PHP core repo, "we did it somewhere in public repo and nobody complained" is not a good stance. People do literally hundreds of things around PHP in public places, but not everything is part of PHP core. phpdbg now is. That involves not only good parts (by-default acceptance by millions of PHP users) but some obligations - like proper discussion and notification. Of course, since master is not stable yet, we have somewhat relaxed rules there, but even then introducing new debugging protocol into PHP core seems to be something that warrants some notification. As a person who spent significant time on implementing and maintaining one of PHP debugging solutions in the past, I, for example, would be interested to take a look into what is being checked into core repo in this regard. However, the first note I see about this happening is the commit messages. And that takes us back to old and not-so-good "check in first, discuss later" times. With project of the size of PHP, it having good process matters no less than having good code. So saying "we had this branch for whole three weeks before merging it into PHP repo" is not really saying much. That said, we are where we are, and I think it would be great if this would somehow server as a starting point for developing a unified protocol for debugging PHP. There are a number of good tools for debugging PHP, and it would be a pity if everybody invented their own protocols and required to install half-dozen of extensions to be compatible with all tools doing the same in slightly different way. We have so many unification efforts with PSR and the spec and so on, I'm pretty sure we can make a protocol that would be workable for all, debugging PHP is not exactly rocket surgery and there are not that many things there that we couldn't find a common ground. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/