hi,

On Mon, Jul 14, 2008 at 11:29 AM, Ulf Wendel <[EMAIL PROTECTED]> 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

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Reply via email to