Dayless Day

PDOv1 was initially a small project created and maintained mostly by 1-2 persons.
Even though it was quite small, it turned out to be a kind of monster which nobody really likes or understands.
Oh.. and did I mention that it never actually worked?

And now we're being forced to have PDOv2, which is of course very much different from PDOv1: it's being developed by a secret group of people (which includes some mysterious "vendors") aand.. it requires signing a legal paper it you want to participate or even read its spec.

PDO does not need a CLA, PDO needs *CARE*.

Doesn't matter how much "vendors" participate in PDO, it's going to be a total failure as long as nobody cares about it.
That was the biggest flaw of PDOv1 and CLA won't magically fix it.

The docs generated by the brand new docu build system PhD ([CVS], [releases]) written by Hanness Magnusson, after several months of development are finally online!

Feel the difference:
   With the old OpenJade/DocBook it took 40-60 minutes to build 'many htmls' version of the manual.
   With PhD it takes less than 2 minutes to build all three formats (`phpweb`, `one big html` and `many htmls`).

Kudos to Bjori!

As you know, there are lies, damned lies and statistics benchmarks.
So here are some more template benchmarks: http://template-bench.iliakantor.ru/, prepared by Ilia Kantor.
Curiously enough, Smarty is on the 5th place, right after the stuff written in C, so think twice before saying it's slow.

IMO it's time to make the development process more organized.
This is my version of what I would like to see as an official set of rules for PHP community.

PHP Seven Commandments

1. Thou shalt obey the Release Master.

2. Thou shalt not commit any patches except for bugfixes after RC stage has started.
Even bugfixes must be discussed with the release master before committing.

3. Remember the coding standards and keep them holy.

4. Thou shalt not forget to add comments to thy code, especially if the code is tricky.

5. Thou shalt not fix a bug only in one of the branches unless it did not exist in the others.
The rule of thumb is to fix it in HEAD first and then backport it.
Forwardporting is not appreciated unless it happens in a matter of hours.

6. Major development goes in HEAD, other branches are created for bugfixes and minor improvements.

7. Thou shalt discuss all new features in internals@.
If nobody pays attention to your proposal, it makes little sense to implement it.

Alexey Rybak has recently rolled out new bugfix release of his template PHP extension - Blitz 0.5.7.
This release fixes a number of minor problems including memory leaks and possible invalid reads and does not affect functionality or speed in any way, so the extension is still blazing fast, but even more stable now.
See more about Blitz here (benchmarks included).

1. Have you ever needed to generate PDF files on-the-fly? (Yes/No)
2. If yes, what did you use for that? (PDFLib/libharu/Other)
3. Did you try PECL/haru or libharu itself? (Yes/No)
4. Are you interested in open source library for PDF generation (written in C)? (Yes/No)
5. Would you like to take part in development/maintenance/testing of such a library? (Yes/No)

I'm thinking to move libharu development under the PHP.net umbrella (Takeshi Kanno, the original author, has just agreed to that), just as we did with GD, but I'm not yet sure if there is a need for it in the community.
At the moment libharu development is de facto stopped because the author lacks time for it and I personally think it would be a great pity to lose this kind of library.

So what do you people think?
Are there any people willing to help?

Derick added 5_3 snapshots to snaps.php.net some minutes ago.
Short list of what you can find there:
- Namespaces
- Late static binding
- __callstatic() magic method
- Accessing static members through $foo::myFunc()
- Fully rewritten ini-parser with .htaccess-like user defined ini files for CGI/FastCGI
- Improved OpenSSL extension
- PCRE 7.4
- other fixes and improvements that will never get into 5_2 branch.

Please test it as tough as you can before the release!

See more about it in Wikipedia.

Short version:
Fix old bugs, don't add new ones.

Long version:
I'm a bit surprised by the amount of new language constructs recently requested on the internals list.

First of all, I should note that none of these requests are supported by patches, so I call them gimme's. "Gimme that feature from language X, I used it once and it's just awesome!!!1111", you know. Quite useless.

Second, people seem to forget the fact that new features do not appear in older versions automagically after they're added into HEAD and old installations tend to live forever very long. So even if this feature does eventually get into the core, for quite a long time you would be able to use it only on your own server because your hosting provider uses good old PHP 4.3.4 (or even PHP3, see this) and is not going to update it because this may break other customers phpBB's.


So here is the new "feature" I would like propose myself: let's make all the existing things working as they should instead of adding a bunch of new features used by a couple of hackers.
If you're bored and have an itch to hack something, take a look at bugs.php.net, I'm sure you'll find it quite entertaining.