Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:38935 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 50315 invoked from network); 14 Jul 2008 11:21:46 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 14 Jul 2008 11:21:46 -0000 Authentication-Results: pb1.pair.com header.from=pierre.php@gmail.com; sender-id=pass; domainkeys=bad Authentication-Results: pb1.pair.com smtp.mail=pierre.php@gmail.com; spf=pass; sender-id=pass Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.198.238 as permitted sender) DomainKey-Status: bad X-DomainKeys: Ecelerity dk_validate implementing draft-delany-domainkeys-base-01 X-PHP-List-Original-Sender: pierre.php@gmail.com X-Host-Fingerprint: 209.85.198.238 rv-out-0506.google.com Received: from [209.85.198.238] ([209.85.198.238:16128] helo=rv-out-0506.google.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 07/65-16791-8C63B784 for ; Mon, 14 Jul 2008 07:21:44 -0400 Received: by rv-out-0506.google.com with SMTP id g37so4503226rvb.23 for ; Mon, 14 Jul 2008 04:21:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=l64n9MQsHSw42Y3V8y0LyxZm+JVo1sfRaTUI24pwuBM=; b=UB/5AJL/aSrmBTaxDkue84I/s6SKdd8i2KLAplsIqC0i+RVFPBiUNgAEiUhRKsSbmL JDo5/PYRaDeF0WCUBtVA9QPZHE6/lQf2JjI3LIidCmQZa7zwZ+6n8bJ/9pDxsxNZBmEV CLVrnvUIH4L0YHjX1sdR+gb01OMS8nSpQVTD8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=Bk8e6MDzvVkmblcet1uNgdzmh3m15+K+ZGHZec2iQrkC6TGYStqmd8IZc010sSIVAd ZcC25EwXv4fQe6w40PJ0KuiLf09kZxDkXFtYr2c0YpntDh4N/fEAO0C0kbSuYN4vanLs aR5NaWKxV4uSJKlsV0qv7BXbFIDrwJEpy0CQw= Received: by 10.140.250.14 with SMTP id x14mr6515279rvh.79.1216034501475; Mon, 14 Jul 2008 04:21:41 -0700 (PDT) Received: by 10.140.178.14 with HTTP; Mon, 14 Jul 2008 04:21:41 -0700 (PDT) Message-ID: Date: Mon, 14 Jul 2008 13:21:41 +0200 To: "Ulf Wendel" Cc: "Lars Strojny" , "Lukas Kahwe Smith" , "PHP Developers Mailing List" , "=?ISO-8859-1?Q?Johannes_Schl=FCter?=" In-Reply-To: <487B1C8E.2010703@phpdoc.de> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <1215966417.4685.14.camel@localhost> <487B1C8E.2010703@phpdoc.de> Subject: Re: [PHP-DEV] tentative 5.3 release plan From: pierre.php@gmail.com ("Pierre Joye") hi, On Mon, Jul 14, 2008 at 11:29 AM, Ulf Wendel wrote: > The PDO_MYSQLND extension, as I call it, is a patched PDO_MYSQL extension. > PDO_MYSQLND is on the TODO list [1]. Yes, why this point has been raised here. > I hardly ever blogged about PDO_MYSQLND as a patch, although it is more of a > patch than a new extension. PDO_MYSQLND reads shorter than a lengthy rather > technical explanation. As blogging is all nice and shiny, php-internals are the place to discuss internals issues. There is also a PDO dedicated list. > However, at some point we "forked" PDO_MYSQL and started to patch it to > optionally support mysqlnd. This was the easiest way to add mysqlnd support > to the PDO MySQL driver (PDO_MYSQL). PDO_MYSQL was the last MySQL extension > in row to be upgraded to support both mysqlnd and the MySQL Client library > (AKA libmysql). ext/mysql and ext/mysqli can already be compiled against the > MySQL Client library, like ever since (= 100% BC), or be compiled against > mysqlnd. Thanks for that, and mysqlnd is used or will be used by default on our windows releases/snaps. > Early versions of the patch did have a very poor quality. By "poor" I mean > "poor" - like 60% of the tests crashing. Things became better in April > (MySQL UC, alpha release). But the April version was still not good enough > to be checked into the PHP 5.3 CVS repository. It was clear that it would > take several more months to get the job done with the resources assigned to > it. Well, if you have resources issues, it is even another good reason to do not "hide" your development in some mysql's site. It is amazing how helpful the PHP developers can be while hunting bugs or improving things. And mySQLnd is a PHP.net software no? > From the mysqlnd development we know that only very few PHP users are > interested in bloody steaks. So, why should bad boy MySQL break the php.net > PHP 5.3 repository and mess up PDO_MYSQL for months instead of stabilizing > the patch first? In particular if there is no pressing reason... As you cernainly noticed already, there is one pressing reason, the freeze of PHP 5.3 will happen in 9 days. As it can be built against libmysql or mysqlnd, why not leave libmysql as defult until it reached an usable state? Please note that usable does not stable nor beta. The other reason is to let us see how it works, to test it smoothly while testing any other part of the core PHP. > Those who want alpha code can get it from us at any time. I could get it at any time with PHP if it was in PHP's cvs. > We did a tough development sprint in the last weeks to make the patch > "ready" for the tentative PHP 5.3 release plan. Our internal release plan > shows no coding between Beta and GA but fixing newly reported bugs. All > coding was planned to be done by the release of a beta - we have reached > some 80% of the beta goals. The freeze and the release following it is not beta but alpha. That hences the reason of our questions. If you reached 80% of the beta goals, why don't you commit it now? > I expect Dmitry to bail out about PDO_MYSQLND quality and performance. > Dmitry/Zend is doing some excellent QA behind the scenes. But I do not > expect any user to complain about us delaying a PHP 5.3 release by checking > in unstable and buggy code. The patch (PDO_MYSQLND) won't break PDO_MYSQL > anymore if it goes into the PHP CVS. The goal of the release phases is to test. If myslqnd happens to be broken and it is not possible to fix it in time for 5.3, it will be dropped or disabled by default. I think that how we worked in every single PHP release (more or less). The more you wait until a commit, the harder it will be for us to test, valid and help you to improve it. Anyway, it is too late to change your way of working with php.net (at least for the 24th). Good luck for the next days ;-) Cheers, -- Pierre http://blog.thepimp.net | http://www.libgd.org