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).
As LibreOffice is approaching its final 3.5.0 release, I’d like to sum up the RTL status for RC1.
So far, 6 RTL related bugs were resolved in the 3.5 cycle (#32530, #34222, #40950, #43790, #43793, #44078), and a few minor issues reported directly to the developer’s mailing list got quick responses. Most importantly, the new features of page break and header/footer not only support RTL but actually looks good. During the LibreOffice conference I was suggested to help with these features, providing feedback, and I’m glade the needed attention was given to it.
Besides that, a few l10n and translation issues were solved in the process of doing the Hebrew translation (which also reflects on other RTL languages). At a few cases, these issue because a general l10n issues which affects all the languages.
In general, I found the core developers responsive to mails about RTL support. I’m sure the talk about RTL problems during the conference helped, as well as being more active in the project and having more personal acquaintance with the developers.
That’s being said, RTL support for LibreOffice still has problems, which I hope will be pushed during the 3.5.x cycles (full list at Bug 43808, the rtl meta bug). As to get some focus regarding was is to be done, I’m listing the top problems:
- #44657 – RTL UI: Horizontal scrollbar in calc main window is broken
- #33302 – brackets inverted in rtl text (mac only)
- #37692 – RTL list numbering reverses its direction
- #42070 – RTL support in broken in presenter Console extension
- #32531 – Incorrect cursor key movement between table cells of different directionality
- #104515 – RTL UI: moving active embedded object to the left moves it to the right (reported for OO.org, but verified in LibO)
- #37128 – Writer saves text alignment of RTL paragraph not according to the ODF specification
I hoped to have the first two done for 3.5.0, but didn’t succeed in getting them fixed. Will keep trying…
PHP 5.4.0 is around the corner, with RC6 released this weekend. With the courtesy of Ondřej 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 the Debian 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.
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).
Oh, shit… yet another step to shrink the public domain.
The Israeli patent registrar have reverted previous ruling regarding patents on software and published a draft for the procedures to accept such patents. The procedures are open to public comments for the next 30 days.
Two years ago the patent registrar have started to consider revising the the issue and got many position papers (e.g. Hamakor’s papter). At the end he decided not to accept patents on software. De facto, at least one such patent (US patent 7,596,609) was accepted to be valid in Israel after that ruling. Now that the rulings is reverted, I guess will see many more software patents granted here. I wonder about the implications on the local software market… hopefully it won’t stagnate due to patent wars such as the ones we see every now and then in the US.
See you there…