The importance of close integration between distribution and upstream

Many package maintainers need to decide when to upload a new version to Debian. Should the upload be done only after the official release, or is there a place for uploads during the development process. In the latter case there’s a need to balance between the benefit of early testing and feedback with the stability and not complitly breaking user’s environment (and package relationships) too often.

With the coming PHP 5.6.0 release, Debian kept being on the cutting edge. Thanks to Ondřej, the new version was available in experimental since alpha1 and in unstable/testing since beta3. Considering the timing of the PHP release related to the Debian freeze, I’m happy we started early, and did the transision to PHP 5.6 a few months ago.

But just following the development releases (betas ,RCs) isn’t enough. Both Ondřej and myself are part of the PHP community, and know the planned timelines, current status and what are the critical points. Such knowlege was very useful this week, when we new 5.6.0 was pending finale tagging before release (after RC4). This made take the report of Debiab bug #759381: “php5: TLS connections broken in 5.6.0 RC4″ seriously and contact the release managers.

First it was a “heads up” and then a real problem. After a quick disscussion (both private mails by me and on github by Ondřej), the relevant commit was reverted by the release managers (Julien Pauli & Ferenc Kovacs), and 5.6.0 was retagged. The issue will get more checks towrads 5.6.1 without any time pressure.

Although 5.6.0 isn’t production for anyone (yet), and like any major release can have issues, the close connectivty betweeen everyone saved compliants from the PHP users and ecosystem. I don’t emgine the issue been sorted so quickely 16 hours later. This is also due to the bug been reported on difference between two close release (regression in RC4 comparing to RC3).

To close the loop, if we’ve uploaded 5.6.0 only after the release, the report would be regression between 5.5.x and 5.6.0, which is obviously much harder to pinpoint. So, I’m not sure I have a good answer for the question in the begining of the post, but for this case our policy proved itself.

Leave a comment

Filed under Debian GNU/Linux, PHP

Testing PHPNG on Debian/Ubuntu

We (at Zend) want to help people get more involved in testing PHPNG (PHP next generation), so we’re started to provide binaries for it, although it’s still a branch on top of PHP’s master branch. See more details about PHPNG on Zeev Suraski’s blog post.

The binaries (64bit) are compatible with Debian testing/unstable and Ubuntu Trusty (14.04) and up. The mod_php is built for Apache 2.4 which all three flavors have.

The repository is at http://repos.zend.com/zend-server/early-access/phpng/

Installation instructions:

# wget http://repos.zend.com/zend.key -O- 2> /dev/null | apt-key add -
# echo “deb [arch=amd64] http://repos.zend.com/zend-server/early-access/phpng/ trusty zend” > /etc/apt/sources.list.d/phpng.list
# apt-get update
# apt-get install php5

For the task of providing these binaries, I had a pleasure of combining my experience as a member of the Debian PHP team and a Debian Developer with stuff more internal to the PHP development process. Using the already existing Debian packaging enabled me to test more builds scenarios easily (and report problems accoredingly). Hopefully this could also be translated back into providing more experimental packages for Debian and making sure Debian packages are ready for the PHP released after PHP 5.6.

1 Comment

Filed under Debian GNU/Linux, PHP

Removal of (some) PHP related software from Debian

The Debian FTP masters have for quite a while a line in their reject FAQ about the PHP license. Despite that, quite a lot of PHP extensions were uploaded to the archive and accepted. Some are being managed/developed in PHP.net’s PECL website, and are done under the umbrella of the PHP Group, which is the group the PHP license is refers to. Over time, we started to see many more extension being developed outside of the PHP group (both technically with sites like github and copyright wise).  This is true to certain degree with the PHP.net’s PEAR  website which has software written in PHP.

The issue has been raised again in October 2013 with php-gearman using the PHP license while having different copyright holders (bug #728196). After discussions (ftp masters, release team & Ondřej), it was agreed that the current interpretation is still relevant, and almost all extensions and applications should be either removed or re-licensed by its upstream. This makes the todo list 41 packages long (full list based on Ondřej Surý’s bug reports). Any help with contacting upstream projects, explaining the situation and requesting a license change would be welcomed. We also need to monitor new release based on fulfilling these requests.

Until such a change happen, with automatic removal of packages from testing, we’re going to see packages disappear after mid July. This has a little wider affect due to package dependencies, but for the moment only on testing (Jessie).

5 Comments

Filed under Debian GNU/Linux, PHP

freedom 0

The license says you can use free and open source software for any reason, but the FBI wouldn’t agree with your questions… Silk Road operator identified by asking a PHP related question on stackoverflow.

See “The Bonehead Mistake That Brought Down an Online Drug-Dealing Empire” on Slate.com

3 Comments

Filed under Uncategorized

Hello free PHP JSON extension

I’ve noticed that my post from three months ago (“Bye bye non-free PHP JSON extension“) was quoted quite often (thanks (: ). But I also noticed that most people didn’t read the post fully, and didn’t see the replacement package.

Hopefully the title of this post will correct that impression. I’d like to indicate the existence of the php5-json package. It’s part of Debian unstable since June 2013 and testing (jessie) since August 2013.

Users who wish to build the free extension on their own are welcome to download it from PECL at http://pecl.php.net/package/jsonc . It’s a good chance to thank Remi Collet for his work on this replacement. I’m happy that the main Linux distributions have already adopted it.

1 Comment

Filed under Uncategorized

Getting patches into PHP (take two)

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

Leave a comment

Filed under PHP

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).

4 Comments

Filed under PHP