On Sponsored Open Source Development
This campaign on Pledgie is an experiment by Derick Rethans to find out whether or not it is feasible to expedite the work on feature requests in Open Source projects such as Xdebug. Since I more or less gave Derick the idea for this experiment, I will try to shine a light on our reasoning for this approach in this blog posting.
For quite some time now, Derick and I occasionally discuss how the collection of code coverage information in Xdebug can be improved so that PHP_CodeCoverage can provide more useful information when you are running your unit tests using PHPUnit, for instance.
At the moment, Xdebug only supports Line Coverage which means it can only tell us whether or not a particular line of code was executed or not. Since a line of code can contain more than one statement, the implementation of Statement Coverage in Xdebug would tell us whether just one statement in a line is executed (which would already count towards Line Coverage) or whether all of its statements are executed at least once while running the tests. Other code coverage metrics that are desirable include Branch Coverage, Path Coverage, and Call Coverage -- and we would like to have them supported by Xdebug and PHP_CodeCoverage as well.
Implementing the data collection for these more sophisticated code coverage metrics in Xdebug and adding support for them in PHP_CodeCoverage is not a small task. And while both Derick and I live and breathe Open Source and like to hack on code things like work and private life do interfere with the development of our Open Source software projects. So with development efforts like this we can either wait for the time when "we have nothing else to do" or try to find support from the people that use the development tools we create on a daily basis that allows to work on new features for said tools sooner rather than later. And although it would be awesome if a single company would approach us with "Hey, we would really like to pay the whole development of these more sophisticated code coverage metrics in Xdebug and PHP_CodeCoverage!" we realise that this is highly unlikely. A platform such as Pledgie, where many individuals can pledge small (and not so small :-) amounts of money could be the solution we are looking for.
Derick's first campain for Xdebug is about a bugfix. And at first glance it might seem rather odd to "demand" money for fixing a bug. As is the case with most complex issues, having a closer look usually clears things up. So what has happened? Xdebug's profiling functionality can dump its information in a format that can be processed and visualized with a tool called KCacheGrind. At the time when Derick implemented this functionality, the data file format used by KCacheGrind was not (well) documented so he had to reverse engineer it. In that process he overlooked the fact that KCacheGrind expects information that he did not provide (namely the
"cfl=" lines that tell KCacheGrind the target of a function or method call). Versions of KCacheGrind prior to the current one used a too relaxed merging of symbols and so it appeared that there was nothing wrong with the data written by Xdebug. Current versions of KCacheGrind, however, are more strict and expect the aforementioned
"cfl=" lines. Without them the visualization of Xdebug profiling information is useless. I noticed this last week and talked to Derick about it. Apparently others had experienced the same issue but he had not had any time yet to investigate it because he is, just like I am, too busy with paid work. Only half-jokingly I told him on Twitter to try Pledgie for this and promised him to pledge money for this if he did (I really need KCacheGrind to work for profiling PHP code). So now you know why we are experimenting with Pledgie at the moment.
With regard to the more sophisticated code coverage metrics that I mentioned in this post our plan is to gather requirements and try to estimate the amount of time needed to implement what we want when I am in London next week. We will keep you posted!