Optimizing for the developer, not the user: PHP misses again


PHP refuses to let you report a bug in any version of PHP older than the absolute latest & greatest.

At work today, we discovered a bug with PDO, the PHP version of Perl's DBI. Turns out if you pass in too many bind parameters, PDO segfaults. Here's the simple program that Pete Krawczyk put together to exercise it.

$dbh = new PDO( 'pgsql:host=localhost;dbname=FOO', 'PASSWORD', '', Array(
    PDO::ATTR_PERSISTENT   => true,
) );

$array = Array();
for ($i = 1; $i < 10; $i++) {
    $array[] = $i;
    $sth = $dbh->prepare('SELECT 1 FROM USERS WHERE CUSTID = ? LIMIT 1');
    while ( $sth->fetch( PDO::FETCH_NUM ) ) {
        # do nothing
    print "PDO lived OK with $i bind" . ($i == 1 ? '' : 's') . "\n";

It's repeatable for us on PHP 5.2.5. So after searching to see that nobody else had already reported it on bugs.php.net, I went to report it.

Alas, when I went to report the bug, I was not able to. My bug happened in 5.2.5, but according to the dialog, that wasn't an option. No, I was left with "Earlier? Upgrade first!"

Latest and greatest only, please!

No, PHP, I am not going to upgrade my PHP installation in order to be blessed with the opportunity of telling you about a segfault in a version of software one minor revision older.

No, PHP, I am not going to spend an hour building and installing another monolithic PHP on some test server so that I might gain the privilege, the privilege I say!, of helping out your project.

What a backwards way to look at open source development! "You must be at least this tall in order to report bugs." What a way to help scare away contributors.

Perhaps you should have a look at how Perl handles it, where we have a wide open ticketing system. There's a tool called perlbug that ships with Perl to encourage responses. The perl5-porters might get some inappropriate bug reports, maybe in a module rather than core Perl, but those are easily closed. We don't put up barriers to reporting. We know how to treat the outside world, because we welcome the feedback.

Get a clue, PHP people.


I agree that this is very very bad from a reporting standpoint. Though PHP and Perl are taking different approaches to what is basically the same problem, you have to update to get fixes in the first place. With Perl we have the advantage of having non-core modules, so in this instance if you found a bug with DBI + 5.8.6 then you could report it, though the bug might be fixed in 5.8.8 so should tim spend time working out a fix for 5.8.6? Your going to have to re-install the new version of DBI any way. The other option is for Tim to tell you "sorry, this is a problem with 5.8.6, if you upgrade to 5.8.8 or 5.8.10 then it will be all better". Again you have to install something.
So as blunt and annoying as it is that PHP does not let you even report issues, they are asking you to upgrade to something more recent where development will actually happen before you make your report in an effort to keep the reporting to things that still need to be reported, not a bunch of stuff that has already been fixed.

Flame bait? You're preaching to the choir, we all love perl, and the php people aren't all that likely to read this...

Perhaps posting it on a PHP forum would help?

they are asking you to upgrade... not a bunch of stuff that has already been fixed.

Yes, I understand that that is what they are doing. They are optimizing for developer time, not the user experience. I think that's exactly backwards.

Given the constraint of volunteer developer time, I'm dubious of the value of encouraging users to do anything other than upgrade.

I'm certain the PHP developers would welcome anyone willing to triage bugs for later versions, though.

Ugh. If Perl Buzz is supposed to be representative of the Perl community in any way, rather than just act as Andy Lester’s soapbox, then let me hereby register that there are at least some of us in the Perl community who find this post embarrassing.

I agree with Aristotle. You may have a point that PHP has a flawed bug tracking system, but the way it's worded is just unnecessary.

One of the things I like about the Perl community is that the more well known people don't tend to indulge in name-calling and finger-pointing. There are plenty of things wrong with any language. It's good if people (especially from outside the community) can point them out constructively. But its senseless taking a "holier than thou" approach.

If Perl Buzz is supposed to be representative of the Perl community in any way, rather than just act as Andy Lester’s soapbox,

I don't know why you'd think that's the case, like there's some sort of "official" status to this blog.

like there’s some sort of “official” status to this blog.
I don’t know why you’d think that’s the case, it wasn’t anywhere in my comment.

I said representative, not official – and why I’d think that, well, the tag line and the “Why?” page for this blog might have something to do with it.

Arguably the problem is yours, not the developers', right? Their app works fine, yours is the one that segfaults. You are the one losing money and time. Why would a developer care, especially when he's not being paid?

Anyway, people expect too much from open source software. It gets better because you fix it, not because you complain about it on the bug tracker.

Jonathan, I agree in general, but after talking to Andy, he and I agree that the perception in the bug tracker is "Go away! We don't want to hear about bugs!"

I prefer a perception of "If you can reproduce a bug in the latest stable or development version, please file it here. If you don't know what that means, please talk to your vendor or hosting provider who should either upgrade or talk to us."

If vendors provide old versions, vendors should support old versions. Vendors should always contact upstream.


On the substance of the posting, I actually agree with Andy. If someone wants to file a bug against an old version, they should be able to. You have two good options for dealing with such bug reports:

  1. If it’s easy to try to reproduce the bug, you do so using the latest version, and then either it’s still a bug and you continue to pursue it as usual, or it’s been fixed in the meantime and you close the bug saying “this is fixed in current stable, please upgrade.”

  2. If it’s complex to try to reproduce the bug, or the version in use by the reporter is really ancient, you ask them whether they can reproduce it on a newer version.

There is little effective difference to what the PHP folks already do. In some easy cases the burden of verifying the presence of a bug on a later stable version is moved to the developers, and the process is more manual.

But the end result is that it’s much easier for people running slightly outdated versions to file bugs, and if such a bug turns out to be current and you fix it in the latest version, you have one bug less. And whether it’s already fixed or you fix it based on their report, the reporter now has a very concrete incentive to go through the upgrade rigmarole.

You of all people should be able to appreciate that last point.

Aristotle, maintaining more than one development version is madness. Either a bug is in the current version of the code, or it isn't.

Would you accept a patch against XML::Atom::SimpleFeed 0.4?


I don’t know where you saw me saying anything about maintaining multiple development versions. In fact I am wondering whether you confused my comment with someone else’s.

Aristotle, you wrote "In some easy cases the burden of verifying the presence of a bug on a later stable version is moved to the developers, and the process is more manual."

... and now that I read that again, I have no idea what I was thinking when I wrote my comment. Please accept my apologies.

I've wondered about this for a while, whether there should be a standardized format for presenting the developer-to-user contract, like a privacy policy. Everybody seems to roll their own, but there's no general template that a new developer can grab and fill in. Some ideas are:

  • End-user FAQ entry for filing bug, pointing to the 'contract'
  • What info to provide, in sorted order of preference -- steps to reproduce, error messages, code triage, patch, etc.
  • Indication of what information and how much of it will improve the chances of getting a bug fixed
  • How best to present the information (text, html, prose, filed bug, etc)
  • How far back you should bother to file bugs
  • What kind of response you'll receive (none, autoresponder, etc)
  • Whether making yourself available (and in what ways) to the developer, should they need more info, will make a difference or not (e.g., special accessibility to you if you have a security issue)
  • Whether you can get notification when the bug is fixed or not
  • Con: when whiners see something on this list they don't like, they'll whine
  • Pro: showing your users you value their feedback by indicating what feedback you'd appreciate
  • Pro: showing users you value their time in that you took the time to let them know how best to spend their time filing a report
  • Pro: helping your users help you more

Debian seems to do a decent job of guiding the user in filing a bug, and embraces one of the perl philosophies that it should be usable for a beginner, and usable for an expert, while still prompting for enough information in this 'Instant gratification takes too long' (Carrie Fisher) world of today. At best, such a contract would cut the time from file to fix at a small additional expense of time for the user, and a much lower amount of time for the developer. At worst, it would at least let the user know when to bother filing a bug and when to work around the problem.

Leave a comment

Job hunting for programmers

Land the Tech Job You Love, Andy Lester's guide to job hunting for programmers and other technical professionals, is available in PDF, ePub and .mobi formats, all DRM-free, as well as good old-fashioned paper.