# tentative 5.3 release plan - Thread: https://externals.io/message/38911 - Original archive: https://news-web.php.net/php.internals/38911 - Started by Lukas Kahwe Smith on 2008-07-11T09:59:51+00:00 - Messages: 31 - Page 1 of 2: messages 1 to 25 (25 per page, add `?page=N` to the URL) - Next page: https://externals.io/message/38911.md?page=2 - Reply by email to internals@lists.php.net - More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt --- ## #38911 — Lukas Kahwe Smith — 2008-07-11T09:59:51+00:00 URL: https://externals.io/message/38911#38911 Hello all, Over the last week we have collected todo/wishlist items for PHP 5.3 [1]. We have tried to get in contact with all the known stakeholders and we have we have gotten enough information from you all that our release plan will be more than tentative, but you never know and common sense always rules over plans. Again the focus areas we see for the coming weeks related to 5.3 are: - namespaces - late static binding - re2c - windows support - minimizing BC support/documentation Additionally we see the following items as very important: - intl extension - phar extension - `E_DEPRECATED` - __callStatic - Garbage Collection - MySQLnd In our dreams someone would also make PDO a focus area, since the number of open bugs is getting ridiculous. This is also a call to the general community to try and help to find a PDO maintainer. In the mean time people not adapt in C might at least try and plow through the bug tickets to find duplicates and verify the open tickets, write tests etc. This already lengthy list is no where a complete listing of all the open items people are hoping to get in. At this point we are calling for a feature freeze [2] by Thursday July the 24th (I will spare you all a specification of a specific timezone, again common sense rules). A week after we plan to release alpha1 (July 31st). From then on we will try to make alpha, beta and eventually RC's in 2-3 week intervals. Note that we moved closures into 5.3. We thought long and hard about this one. This is not the opening of the flood gates of engine feature additions. The reason why we added it was that we had pretty much universal letters of support for this patch, that it seems fairly nonintrusive and that the debates over the feature seem to have resulted in general agreement on the syntax. More over with a well documented RFC we feel the chances are fairly good that we will not have any big nasty surprises. That being said, the second we start seeing that closures have issues that take away from resources from the above noted items, we will most likely pull the patch from 5.3. We are hoping to have a stable release of PHP 5.3 out by between mid September and mid October. regards, Lukas Kahwe Smith mls@pooteeweet.org [1] http://wiki.php.net/todo/php53 [2] We will consider exceptions on a case by case basis until alpha2. Though there is little chance we will allow engine feature additions. So for the most part we will allow only fairly self contained changes within specific extensions. Let us know ASAP if you still have something in the pipeline (this includes any item on the todo list), that you feel you cannot complete until the 24th. --- ## #38916 — Sebastian Bergmann — 2008-07-12T14:32:08+00:00 URL: https://externals.io/message/38911#38916 · In reply to: #38911 Lukas Kahwe Smith wrote: > Note that we moved closures into 5.3. Awesome! Too make testing closures in PHP_5_3 easy, the current state of closures should be merged ASAP from HEAD to the branch. The patch that in linked from the wiki is out of sync with HEAD AFACIS. Thanks! Sebastian -- Sebastian Bergmann http://sebastian-bergmann.de/ GnuPG Key: 0xB85B5D69 / 27A7 2B14 09E4 98CD 6277 0E5B 6867 C514 B85B 5D69 --- ## #38919 — Andi Gutmans — 2008-07-13T03:57:50+00:00 URL: https://externals.io/message/38911#38919 · In reply to: #38916 I am sure Dmitry will be happy to help out on that on Monday. Andi > -----Original Message----- > From: news [mailto:news@ger.gmane.org] On Behalf Of Sebastian Bergmann > Sent: Saturday, July 12, 2008 7:32 AM > To: internals@lists.php.net > Subject: Re: [PHP-DEV] tentative 5.3 release plan > > Lukas Kahwe Smith wrote: > > […] > > Awesome! Too make testing closures in PHP_5_3 easy, the current state of > closures should be merged ASAP from HEAD to the branch. The patch that > in linked from the wiki is out of sync with HEAD AFACIS. > > Thanks! > Sebastian > > -- > Sebastian Bergmann http://sebastian-bergmann.de/ > GnuPG Key: 0xB85B5D69 / 27A7 2B14 09E4 98CD 6277 0E5B 6867 C514 B85B 5D69 --- ## #38920 — Lars Strojny — 2008-07-13T16:26:57+00:00 URL: https://externals.io/message/38911#38920 · In reply to: #38911 Hi Lukas, hi Johannes, Am Freitag, den 11.07.2008, 11:59 +0200 schrieb Lukas Kahwe Smith: > - MySQLnd what's with PDO MySQLnd, will it be part of 5.3? cu, Lars --- ## #38921 — Pierre Joye — 2008-07-13T16:33:02+00:00 URL: https://externals.io/message/38911#38921 · In reply to: #38920 Hi Lars, 2008/7/13 Lars Strojny : > Hi Lukas, hi Johannes, > > Am Freitag, den 11.07.2008, 11:59 +0200 schrieb Lukas Kahwe Smith: > > […] > > what's with PDO MySQLnd, will it be part of 5.3? It is the case already. All MySql extension uses ext/mysqlnd by default (at least on windows ;). Cheers, -- Pierre http://blog.thepimp.net | http://www.libgd.org --- ## #38922 — Pierre Joye — 2008-07-13T17:46:21+00:00 URL: https://externals.io/message/38911#38922 · In reply to: #38921 hi Lars, Johannes, Lukas, > Hi Lars, > > 2008/7/13 Lars Strojny : > > […] > > It is the case already. All MySql extension uses ext/mysqlnd by > default (at least on windows ;). So I was wrong. It is not yet in. I really wonder why it is not developed in php's repository directly. As it can build against both libmysql and mysqlnd, it can have no impact on the existing code until it is stable. Also, reading the 5.3 todos: > Patch PDO_MYSQL to optionally support mysqlnd library in addition to the MySQL client library, Please note that we will not use libmysql anymore on Windows from 5.3+. Correct me if I'm wrong but was It the plan since the introduction of MySqlnd to completly drop libmysql so mysql can continue his stuff on the gpl/commercial side without bother with PHP (translation of the "gift to the PHP community" :). Cheers, -- Pierre http://blog.thepimp.net | http://www.libgd.org --- ## #38924 — Lester Caine — 2008-07-14T06:35:27+00:00 URL: https://externals.io/message/38911#38924 · In reply to: #38922 Pierre Joye wrote: > hi Lars, Johannes, Lukas, > > > > […] > > So I was wrong. > > It is not yet in. I really wonder why it is not developed in php's > repository directly. As it can build against both libmysql and > mysqlnd, it can have no impact on the existing code until it is > stable. > > Also, reading the 5.3 todos: > > > […] > > Please note that we will not use libmysql anymore on Windows from 5.3+. > > Correct me if I'm wrong but was It the plan since the introduction of > MySqlnd to completly drop libmysql so mysql can continue his stuff on > the gpl/commercial side without bother with PHP (translation of the > "gift to the PHP community" :). Are those of us who can't build our own windows binaries still going to be forced to have it enabled by default? :( Perhaps that is another reason for getting my customers over to Linux on the servers :) -- Lester Caine - G8HFL ----------------------------- Contact - http://lsces.co.uk/lsces/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk// Firebird - http://www.firebirdsql.org/index.php --- ## #38925 — Lars Strojny — 2008-07-14T06:55:26+00:00 URL: https://externals.io/message/38911#38925 · In reply to: #38924 Hi Lester, Am Montag, den 14.07.2008, 07:35 +0100 schrieb Lester Caine: > Perhaps that is another reason for getting my customers over to Linux > on the servers :) If this is true, we should definitely leave it that way :) cu, Lars --- ## #38926 — Stefan Esser — 2008-07-14T07:23:37+00:00 URL: https://externals.io/message/38911#38926 · In reply to: #38924 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello Lester, I wonder if you could enlight us, why you hate ext/mysql? Do you believe the urban legend that smaller .exe/.dll are loaded faster? Maybe you have never heard of shared code segments... Every readable only segment is shared on windows. So there is only one copy of the .dll/.exe loaded for ALL processes using it... Stefan Esser -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkh6/vkACgkQSuF5XhWr2njBNQCgk+JHAUN7cLDA0oSgmU90bd8r RJIAn1mCKkEsPHQq6W6Fa++MuQRJ05xa =J5LW -----END PGP SIGNATURE --- ## #38928 — Ulf Wendel — 2008-07-14T09:29:50+00:00 URL: https://externals.io/message/38911#38928 · In reply to: #38920 Lars Strojny schrieb: > Hi Lukas, hi Johannes, > > Am Freitag, den 11.07.2008, 11:59 +0200 schrieb Lukas Kahwe Smith: > > […] > > what's with PDO MySQLnd, will it be part of 5.3? The PDO_MYSQLND extension, as I call it, is a patched PDO_MYSQL extension. PDO_MYSQLND is on the TODO list [1]. 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. 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. 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. 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... Those who want alpha code can get it from us at any time. 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. 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. Johannes is working on a 3-stars change (***zval) to both PDO and PDO_MYSQLND which I would like to test first before the patch (PDO_MYSQLND) goes into the PHP 5.3 CVS. That's days, not weeks, just enough time to see people discuss the tentative PHP 5.3 release plan and the PDO_MYSQLND entry on it. Ulf [1] http://wiki.php.net/todo/php53 --- ## #38930 — Lukas Kahwe Smith — 2008-07-14T09:34:00+00:00 URL: https://externals.io/message/38911#38930 · In reply to: #38928 > Lars Strojny schrieb: > > […] > > 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. > > 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. > > Johannes is working on a 3-stars change (***zval) to both PDO and > PDO_MYSQLND which I would like to test first before the patch > (PDO_MYSQLND) goes into the PHP 5.3 CVS. That's days, not weeks, > just enough time to see people discuss the tentative PHP 5.3 release > plan and the PDO_MYSQLND entry on it. The patch should be in CVS by July 24th. regards, Lukas Kahwe Smith mls@pooteeweet.org --- ## #38932 — Ulf Wendel — 2008-07-14T10:02:23+00:00 URL: https://externals.io/message/38911#38932 · In reply to: #38930 Lukas Kahwe Smith schrieb: > > > > > […] [snip] > > […] > > > The patch should be in CVS by July 24th. It will be ready. I even dared to take a few vacation days last week... Ulf --- ## #38933 — Jani Taskinen — 2008-07-14T10:14:55+00:00 URL: https://externals.io/message/38911#38933 · In reply to: #38928 Ulf Wendel wrote: > 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. What about the already reported (a.k.a. "old") bugs? :) --Jani --- ## #38934 — Lester Caine — 2008-07-14T10:43:19+00:00 URL: https://externals.io/message/38911#38934 · In reply to: #38926 Stefan Esser wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Hello Lester, > > I wonder if you could enlight us, why you hate ext/mysql? > > Do you believe the urban legend that smaller .exe/.dll are loaded faster? > > Maybe you have never heard of shared code segments... Every readable > only segment is shared on windows. So there is only one copy of the > .dll/.exe loaded for ALL processes using it... I don't use MySQL and I never have. WHEN I run the installation stuff for bitweaver, the only database available is Firebird, simply because it's the only active interface, so there are no problems and no confusion. I don't want other packages running - I don't want to have to install MySQL so as long as I can SWITCH OFF anything that I don't need on the server I don't have a problem. The problem comes when you run `phpinfo()` and it is cluttered with things that are simply not being used. -- Lester Caine - G8HFL ----------------------------- Contact - http://lsces.co.uk/lsces/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk// Firebird - http://www.firebirdsql.org/index.php --- ## #38935 — Pierre Joye — 2008-07-14T11:21:41+00:00 URL: https://externals.io/message/38911#38935 · In reply to: #38928 hi, > 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 --- ## #38936 — Ulf Wendel — 2008-07-14T11:30:31+00:00 URL: https://externals.io/message/38911#38936 · In reply to: #38933 Jani Taskinen schrieb: > Ulf Wendel wrote: > > > […] > > What about the already reported (a.k.a. "old") bugs? :) Have a look at the bug overview at http://blog.ulf-wendel.de/?p=190 . Many old PDO_MYSQL bugs have been fixed. I don't claim the list to be complete. If you are worried about any particular bug, let me know. A good number of reported bugs are PDO bugs not driver bugs. For example the LIMIT issue is reported frequently as a PDO_MYSQL bug although it is a side-effect of the PDO SQL parser [1]. Several new bugs have been found in PDO_MYSQL and PDO. We have not worked on the PDO bugs as we have focussed on our driver first. Ilia fixed some of the major ones. Other bug reports are about minor issues. The thingie Johannes is working on is teaching PDO not to copy zvals from the drivers but supporting drivers who want to manage zvals themself, such as mysqlnd does. This change will prevent that we run into another issue where mysqlnd and PDO logic clash and PDO rejects a number and returns `NULL` instead of the number - the only show stopper I know of. All other issues I see are rather minor ones. Cross platform testing has been performed on: AIX 5.3 ppc64 FC4 x86 FreeBSD 6 x86, x86_64 HP UX 11.23 ia64 MacOS X 10.4 ppc32, x86 RHEL 3 ia64, x86, x86_64 RHEL 4 ia64, x86, x86_64 SLES 9 ia64, x86, x86_64 Suse 10.3 x86, x86_64 Win32 Solaris 8 to 10 failed to compile SPL with (Sun) CC last wednesday. I haven't looked into it yet. Win64 is missing. Anyway, the first X-platform results are very good, given that I haven't "tuned" the tests for x-platform compatibility yet. Ulf [1] http://blog.ulf-wendel.de/?p=191 --- ## #38937 — Jani Taskinen — 2008-07-14T11:38:56+00:00 URL: https://externals.io/message/38911#38937 · In reply to: #38936 Well, connection issues using mysqlnd seems to be pretty commonly reported, like this: http://bugs.php.net/45468 There are 20 open reports currently: http://bugs.php.net/search.php?cmd=display&bug_type[]=MySQL+related&bug_type[]=MySQLi+related&status=Open&order_by=id&phpver=5&limit=50 I don't know if these are on some list in some blog, I only check the php bug system for open issues. --Jani Ulf Wendel wrote: > Jani Taskinen schrieb: > > […] > > Have a look at the bug overview at http://blog.ulf-wendel.de/?p=190 . > Many old PDO_MYSQL bugs have been fixed. I don't claim the list to be > complete. If you are worried about any particular bug, let me know. > > A good number of reported bugs are PDO bugs not driver bugs. For example > the LIMIT issue is reported frequently as a PDO_MYSQL bug although it > is a side-effect of the PDO SQL parser [1]. > > Several new bugs have been found in PDO_MYSQL and PDO. We have not > worked on the PDO bugs as we have focussed on our driver first. Ilia > fixed some of the major ones. Other bug reports are about minor issues. > > The thingie Johannes is working on is teaching PDO not to copy zvals > from the drivers but supporting drivers who want to manage zvals > themself, such as mysqlnd does. This change will prevent that we run > into another issue where mysqlnd and PDO logic clash and PDO rejects a > number and returns `NULL` instead of the number - the only show stopper I > know of. All other issues I see are rather minor ones. > > Cross platform testing has been performed on: > > AIX 5.3 ppc64 > FC4 x86 > FreeBSD 6 x86, x86_64 > HP UX 11.23 ia64 > MacOS X 10.4 ppc32, x86 > RHEL 3 ia64, x86, x86_64 > RHEL 4 ia64, x86, x86_64 > SLES 9 ia64, x86, x86_64 > Suse 10.3 x86, x86_64 > Win32 > > Solaris 8 to 10 failed to compile SPL with (Sun) CC last wednesday. I > haven't looked into it yet. Win64 is missing. Anyway, the first > X-platform results are very good, given that I haven't "tuned" the tests > for x-platform compatibility yet. > > Ulf > > [1] http://blog.ulf-wendel.de/?p=191 --- ## #38938 — Lars Strojny — 2008-07-14T11:58:11+00:00 URL: https://externals.io/message/38911#38938 · In reply to: #38936 Hi Ulf, Am Montag, den 14.07.2008, 13:30 +0200 schrieb Ulf Wendel: [...] > Cross platform testing has been performed on: > > AIX 5.3 ppc64 > FC4 x86 > FreeBSD 6 x86, x86_64 > HP UX 11.23 ia64 > MacOS X 10.4 ppc32, x86 > RHEL 3 ia64, x86, x86_64 > RHEL 4 ia64, x86, x86_64 > SLES 9 ia64, x86, x86_64 > Suse 10.3 x86, x86_64 > Win32 Is there a way to checkout the source. I would love to test PDO_MYSQLND. cu, Lars --- ## #38939 — Ulf Wendel — 2008-07-14T11:59:40+00:00 URL: https://externals.io/message/38911#38939 · In reply to: #38937 Jani Taskinen schrieb: > Well, connection issues using mysqlnd seems to be pretty commonly > reported, like this: > > http://bugs.php.net/45468 Aaah, you're talking about mysqlnd @ ext/mysql[i] - different story altogether. > There are 20 open reports currently: > > http://bugs.php.net/search.php?cmd=display&bug_type[]=MySQL+related&bug_type[]=MySQLi+related&status=Open&order_by=id&phpver=5&limit=50 It seems that Pierre's hypothesis that the community would take care and help out is wrong. Andrey and I work on a different projects since a few months. Its been only a development sprint that made me getting back to PHP. No doubt we need to fix them. Andrey ^. Ulf --- ## #38940 — Lukas Kahwe Smith — 2008-07-14T12:01:57+00:00 URL: https://externals.io/message/38911#38940 · In reply to: #38939 > Jani Taskinen schrieb: > > […] > > Aaah, you're talking about mysqlnd @ ext/mysql[i] - different story > altogether. > > > […] > > It seems that Pierre's hypothesis that the community would take care > and help out is wrong. Andrey and I work on a different projects > since a few months. Its been only a development sprint that made me > getting back to PHP. there are also a few in PECL: http://pecl.php.net/bugs/search.php? cmd=display&status=Open&package_name[]=PDO_mysql generally all of PDO suffers from the lack of maintainers .. regards, Lukas Kahwe Smith mls@pooteeweet.org --- ## #38941 — Ulf Wendel — 2008-07-14T12:20:11+00:00 URL: https://externals.io/message/38911#38941 · In reply to: #38940 Lukas Kahwe Smith schrieb: > there are also a few in PECL: > http://pecl.php.net/bugs/search.php?cmd=display&status=Open&package_name[]=PDO_mysql Ok, that's PDO_MYSQL. We checked both pecl.php.net and php.net bug lists. Are there any plans to improve the PHP bug systems to allow: - prioritizing a bug - add progress reports This would help to, for example, mark http://pecl.php.net/bugs/bug.php?id=12401 as "in progress" or is that "assigned". But "assigned" often means "yes, I should, but next year...". Ulf --- ## #38942 — Lukas Kahwe Smith — 2008-07-14T12:23:55+00:00 URL: https://externals.io/message/38911#38942 · In reply to: #38941 > Lukas Kahwe Smith schrieb: > > […] > > Ok, that's PDO_MYSQL. We checked both pecl.php.net and php.net bug > lists. Are there any plans to improve the PHP bug systems to allow: > > - prioritizing a bug > - add progress reports > > This would help to, for example, mark http://pecl.php.net/bugs/bug.php?id=12401 > as "in progress" or is that "assigned". But "assigned" often means > "yes, I should, but next year...". check with barry .. also note http://wiki.php.net/issuetracker regards, Lukas Kahwe Smith mls@pooteeweet.org --- ## #38943 — Ulf Wendel — 2008-07-14T12:58:23+00:00 URL: https://externals.io/message/38911#38943 · In reply to: #38938 Hi Lars! Lars Strojny schrieb: > Is there a way to checkout the source. I would love to test PDO_MYSQLND. Not yet. Andrey will need a day or so. I've CC'd him. He can post instructions here. The internal mysqlnd repostory, which includes the code for PDO_MYSQLND, was among the first to be migrated to Bazaar. This was long before the migration of the MySQL trees was announced [1] and long before the infrastructure for public access was ready. Blame me for not pushing on public access to the bzr repro earlier... Ulf [1] http://blogs.mysql.com/kaj/2008/06/19/version-control-thanks-bitkeeper-welcome-bazaar/ --- ## #38990 — Christopher Jones — 2008-07-15T21:09:33+00:00 URL: https://externals.io/message/38911#38990 · In reply to: #38911 Lukas Kahwe Smith wrote: > In our dreams someone would also make PDO a focus area, since the number > of open bugs is getting ridiculous. This is also a call to the general > community to try and help to find a PDO maintainer. In the mean time > people not adapt in C might at least try and plow through the bug > tickets to find duplicates and verify the open tickets, write tests etc. For PHP 5.3 on, I'd be happy to see the Windows builds of PDO_OCI only produce php_pdo_oci.dll and no longer also build php_pdo_oci8.dll. The latter uses an older set of Oracle client libraries that allows connections to Oracle 7 and 8.0 databases. The impact is that users on Windows will no longer be able to connect to the older databases unless they compile the extension themselves. The benefit is reduced user confusion and PDO maintenance. The change is to remove the pdo-oci8 section of ext/pdo_oci/config.w32 and tidy up associated Windows DLL release infrastructre. Chris -- Christopher Jones, Oracle Email: christopher.jones@oracle.com Tel: +1 650 506 8630 Blog: http://blogs.oracle.com/opal/ Free PHP Book: http://tinyurl.com/f8jad --- ## #38991 — Lukas Kahwe Smith — 2008-07-15T21:15:11+00:00 URL: https://externals.io/message/38911#38991 · In reply to: #38990 > > Lukas Kahwe Smith wrote: > > > […] > number > > […] > general > > […] > tests etc. > > For PHP 5.3 on, I'd be happy to see the Windows builds of PDO_OCI only > produce php_pdo_oci.dll and no longer also build php_pdo_oci8.dll. > The latter uses an older set of Oracle client libraries that allows > connections to Oracle 7 and 8.0 databases. > > The impact is that users on Windows will no longer be able to connect > to the older databases unless they compile the extension themselves. > > The benefit is reduced user confusion and PDO maintenance. > > The change is to remove the pdo-oci8 section of ext/pdo_oci/config.w32 > and tidy up associated Windows DLL release infrastructre. I guess for windows it just comes down to what we bundle. We could still support older Oracle versions with an optional download. If we want to be super fancy, we might even include a note in an error message when trying to connect to older versions that there is pdo_oci8 available as an optional download from win.php.net (or whatever our pecl4win.php.net replacement will be). regards, Lukas Kahwe Smith mls@pooteeweet.org --- Next page: https://externals.io/message/38911.md?page=2