Category Archives: PHP

11/08/2013 · 8:49 pm

Getting patches into PHP (taketwo)

Two months ago I complained about how hard it was to get patches into PHP as the core member didn’t give much attention for pull requests on github. After posting it on the blog, I raised the issue in the developers mailing list and was suggested to join and help.

A month ago, I started sending a weekly report about new / pending / merged / closed pull requests and got cooperation from the community with reviewing the pull requests and processing them. In this period 40 requests were dealt with (obviously not all merged), and much more are work in progress while the developers are commenting on the requests.

The credit is obviously for the contributors for the patches and the core developers for the work. Stas Malyshev was of special help with this change.

You’re welcome to follow at https://github.com/php/php-src/pulls

Filed under PHP

05/06/2013 · 10:36 am

Getting patches intoPHP

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://http://www.zjjv.com///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).

Filed under PHP

01/06/2013 · 4:02 pm

Bye bye non-free PHP JSONextension

PHP 5.5 rc2 was recently uploaded to Debian unstable by Ondej Sur. Along side the new PHP version and its features the PHP team has dealt with the JSON extension being non-free because of the “The Software shall be used for Good, not Evil” license (see debian #692613).

php5 (5.5.0~rc1+dfsg-1) experimental; urgency=low









    [...]




  * Add dfsg-repack.sh script to remove non-free JSON module




    (Closes: #692613)




  * Remove php5-json from Provides, since that's no longer true









 -- Ondej Sur <ondrej@debian.org>  Fri, 17 May 2013 14:41:41 +0200

A package with a DFSG replacement for the JSON extension is waiting in the NEW queue and should be available soon. The new JSON extension was done by Remi Collet (PHP developer and Fedora’s PHP maintainer). Review and patches are welcomed, code is available at https://github.com/remicollet/pecl-json-c . I hope the PHP project will adopt the solution, after claiming they won’t fix it themselves (see php.net #63520).

Filed under Debian GNU/Linux, PHP

27/01/2012 · 3:21 am

PHP 5.4 @Zend

As a Linux integration guy at Zend, most of my time is spent in compiling PHP related code or dealing with the variety of Linux distributions we support. With the coming release for PHP 5.4, we (at Zend) had some interesting stuff going on.

As part of the RC phase, I got to check the status of the 50-60 PHP extensions we provide, especially the PECL extensions which have different release cycles than the main PHP. With minor versions, this usually doesn’t really matter, but for major versions this means that some extensions need a little bit of love and fixes to work well with the new PHP version. This of course with the help of our developers.

The changes are usually one-liners due to a variable type change, or finding commits in the extension’s SCM and applying/back-porting it to the current versions (e.g. pecl memcache). Our policy regarding the patches we have, is that they should at least be sent to upstream (a core member or a bug report, e.g. #55703). I think I’m in the best position to enforce that patch policy, so in a few recent cases, I found myself asking one of our developers if the patch he sent me was already accepted upstream before willing to take it into the build process (in this case they are used temporarily, till we’ll work with the next RC or final release).

While most people build PHP as a final and standalone product, we also test it against ZendServer (or the other way around, depends on your POV). This helps to discover problems related to and implications of the changes done in the major version. During the PHP 5.4 RC cycle (which is still not finished), we had, more than a few times, that an internal problem discovered led to debugging, code reviewing and sending feedback (and patches when relevant) to the PHP project. Providing fixes for the issues found, helps having PHP in a better shape for release. At least for me, that’s one of the fun parts of work – getting the chance to contribute back to the community (or at least making sure others do, as I don’t write the patches myself).

Filed under PHP

22/01/2012 · 12:52 am

PHP 5.4 @Debian

PHP 5.4.0 is around the corner, with RC6 released this weekend. With the courtesy of Ondej Sur it’s already available in experimental.

Earlier this week, Raphael Geissert, tested some PHP extensions with the new version and reported 16 bugs (severity: important) against those who failed to build with PHP 5.4. As they will become RC bugs when 5.4.0 will enter unstable (probably around mid February), I preferred to handle them sooner than later. The result is 3 patches sent (one already uploaded) and 5 NMUs done.

During the process I poked through a lot of upstream SCMs. In the way I found out a trivial change was done in PECL’s SVN two years ago for all the extensions located there, which got me suspicious regarding some extensions we have. For non PECL hosted extensions, I had to track if and when a fix was done and use it for building or do a trivial fix myself. Packages using the 3.0 (quilt) source format were extremely easy to fix, and I was quite happy it generally went fast.

In general I’m a passive subscriber to theDebian PHP Maintainers mailing list, and finally could help actually and not just reply emails. For me it’s also doing some Debian work after a few months of focusing on the coming LibreOffice 3.5 release.

update [26/1/2012]:

From the 16 issues, only 2 aren’t fixed already or will be on the next upstream release. As their upstreams are dead, this is in the hands or the debian people, at least till they’ll FTBFS on unstable (instead of experimental).

Filed under Debian GNU/Linux, PHP