Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:35165 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 56735 invoked by uid 1010); 4 Feb 2008 09:31:47 -0000 Delivered-To: ezmlm-scan-internals@lists.php.net Delivered-To: ezmlm-internals@lists.php.net Received: (qmail 56719 invoked from network); 4 Feb 2008 09:31:47 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 4 Feb 2008 09:31:47 -0000 Authentication-Results: pb1.pair.com smtp.mail=derick@php.net; spf=unknown; sender-id=unknown Authentication-Results: pb1.pair.com header.from=derick@php.net; sender-id=unknown Received-SPF: unknown (pb1.pair.com: domain php.net does not designate 82.94.239.7 as permitted sender) X-PHP-List-Original-Sender: derick@php.net X-Host-Fingerprint: 82.94.239.7 mail.jdi-ict.nl Linux 2.6 Received: from [82.94.239.7] ([82.94.239.7:60476] helo=mail.jdi-ict.nl) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 4E/57-07314-77BD6A74 for ; Mon, 04 Feb 2008 04:31:41 -0500 Received: from localhost (localhost [127.0.0.1]) by mail.jdi-ict.nl (8.13.7/8.12.11) with ESMTP id m149VKfZ027353; Mon, 4 Feb 2008 10:31:20 +0100 Date: Mon, 4 Feb 2008 10:31:20 +0100 (CET) X-X-Sender: derick@kossu.ez.no To: Steph Fox cc: internals In-Reply-To: <01c801c865d8$2e837e90$c6fc1f3e@foxbox> Message-ID: References: <01c801c865d8$2e837e90$c6fc1f3e@foxbox> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=UTF-8 Subject: Re: [PHP-DEV] Splitting the subject: the PECL/PHP relationship From: derick@php.net (Derick Rethans) On Sat, 2 Feb 2008, Steph Fox wrote: > 1) Distribution woes need to end. With the work Greg's been doing lately on > PHP_Archive/Phar, that's very close to being attainable now in the physical > 'getting PECL'd extensions out to people' sense, but unless people are running > CLI or CGI or have access to their own php.ini they still can't do much with > those extensions. So we have to seriously consider how to recommend extensions > to hosts, other than by shipping them with the PHP core. > > 2) Maintenance status needs to be part of the equation. > > 3) Stability needs to be part of the equation. > > 4) Appropriateness to a given PHP branch needs to be part of the equation. > > 5) CS and documentation need to be part of the equation. > > Thoughts? Yeah, my main concern is actually not with the one above, except for 2) perhaps. The brilliant thing to have everything in core, is that it gets checked out, updated, etc like all other standard parts. Becaus of this compile errors and other related issues are *quickly* discovered - this is especially important when it comes to OS-differences. regards, Derick