Getting patches into PHP

One of the various ways to measure an open source project is the way it encourages and accepts patches from community members (or future members). The various open source projects I’m involved with have many ways to send patches: mailing list, bug tracking systems and more recently pre-commit tools for peer review (such as gerrit). Another popular option is to use github’s pull request feature for this. Personally, I find it too complex for simple patches and would prefer gerrit over it.

As part of my work at Zend, I try to make sure patches are sent back upstream. Comparing to other open source projects I know,¬† it seems to me that PHP isn’t open enough for contributions. This might be just my private case, but if not, it would be discouraging people to contribute and blocking the community from expanding.

6 Months ago I submitted¬† patch to #36103 (patch is at #63767), but no response. A month ago I submitted a simple patch to FPM’s shell script (#64764), and no response there as well.

To ease things up, I’ve created a github fork of the php-src repository and sent pull requests with each of the patches (as suggested at http://php.net/git-php.php). Even edited the bugs reports with the pull request details (as they provide such integration). I’m waiting to see if this will trigger a more rapid review process from the project. For the simple patch, I got a response very fast from a user, but still waiting for a core member to check it.

Going over the pull requests (both open and closed), I’m not too optimistic about having the patches merged, judging by past merged patches (most of them are at least 2 months) and by the open patches (e.g. a typos fix patch is waiting for month).

About these ads

4 Comments

Filed under PHP

4 responses to “Getting patches into PHP

  1. Posting a message to php-dev mailing list is usually the best way to get a response, the bug tracker can be under-staffed quite often.

  2. Stuart

    My experience as a bug reporter and the php project is even worse. On several bugs, the only reply I ever got was “please try with latest CVS snapshot” and when you said “bug is still there” you’d get exactly the same request again and again until you eventually got bored of it. The bug would then be automatically closed as being “moreinfo” for too long. It’s a perfect system… especially when there was a 3-line reproduce case that the triager could have used clearly laid out in the bug report and there were no commits touching the problematic part of the code base at all.

    I, like so many others, just gave up on the language entirely. If the core developers can’t use a trivial reproduce case to check a bug or think that random changes in other parts of the code might accidentally fix things in their code base, then it’s not a sustainable project and really is the mickey-mouse crap that it is often disparaged as. Sad really… but it doesn’t surprise me that your patches languish for months or more.

    • As much as I understand that frustration, I’ve been on the other side doing bug triage. Sometime asked you to reproduce the bug/verify the fix it the best thing to do, although it’s annoying.

  3. Pingback: Getting patches into PHP (take two) | Free Software Universe

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s