Things have been progressing well with the GTK-VNC widget. The 0.3.0 release a few weeks back fixed a couple of co-routine race conditions, fixed portability to Solaris and added compatability for UltraVNC brokenness – it claims support for RFB version 3.4 which doesn’t technically exist. 0.3.1 was a brown paper bag release a day later, due to the ‘make dist’ process going wrong with 0.3.0; say no more. Today Anthony released version 0.3.2 which adds a GThread based co-routine implementation to provide portability to platforms lacking ucontext support (yes I’m looking at you Windows/cygwin). It also adds support for the RRE server encoding which is a zlib compressed format, although not commonly used its in the spec so its worth supporting.
For the next releases we’ll have support for the Tight encoding as used by TightVNC – this is a more advanced variant on RRE, in some cases using JPEG as its compression method which is interesting. We’re also in communication with the VMWare team to see if we can write code to support the RFB extensions, for which they recently got official extension numbers assigned. We decided to apply the ‘release early, release often’ mentality with earnest, and thus we’re aiming to have regular monthly releases for the forseeable future. Meanwhile John is continuing to develop Vinagre, a long overdue modern VNC client taking full advantage of the GNOME infrastructure & desktop integration points.
If you are a Perl developer you may have come across CPANTS which analyses and ranks all distributions and authors on CPAN based on their Kwalitee score. To quote…
What is a good module? That's hard to say.
What is good code? That's also hard to say.
"Quality" is not a well-defined term in computing ... and especially not Perl.
One man's Thing of Beauty is another's man's Evil Hack
Since we can't define quality, how do we write a program to assure it?
Kwalitee: It looks like quality, it sounds like quality, but it’s not quite quality.
I was rather disappointed to discover my own Kwalitee scores were rather poor so have been spending time to improve matters. The key to this is to run a test to check the Kwalitee score of a new release before uploading it to CPAN. Conveniently the very code used to generate the rankings is available to download and run offline in the form of the Module-CPANTS-Analyse. Inconveniently this wasn’t in Fedora…until today. I finally got all the dependent modules through review and built for rawhide, with F-8 to follow shortly… So now if you want to test the Kwalitee of your Perl modules before release just run:
# yum install perl-Module-CPANTS-Analyse
# cpants_lint.pl /path/to/my/module.tar.gz
It already helped me get Test-AutoBuild perfect…
$ cpants_lint.pl Test-AutoBuild-1.2.2.tar.gz
Checked dist Test-AutoBuild-1.2.2.tar.gz
Kwalitee rating 112.50% (27/24)
Congratulations for building a 'perfect' distribution!
112.50% you might wonder ? Yes, indeed. Only 24 of the checks are considered mandatory at this time. The other 3 are optional, but good practice none-the-less. To get to 100% you need to pass all the mandatory checks. If you manage this, then passing any optional checks will give you an additional boost.
I finally got around to doing some more work on Test-AutoBuild – a build and test automation framework for upstream developers. It checks sources out of SCM repos (CVS, Subversion, SVK, GNU Arch, Mercurial, Perforce), runs any build and test processes. It detects any RPMs generated during the build and publishes them in a YUM repo. It also publishes HTML status pages showing build logs, list of generated packages, any artifacts generated (eg, code test coverage reports, API documentation) and changelogs from the SCM repo. It is a similar system to CruiseControl, but is more powerful since it directly understands the idea of module dependancies, and so can intelligently manage chained builds of multiple dependant modules. We use this in the ET group for testing our virtualization stack. Our nightly builder builds libvirt and gtk-vnc first, then builds virt-viewer and virt-install against these builds, and finally builds virt-manager against all of them. So any change in libvirt gets validated to make sure it doesn’t break apps using libvirt. Since autobuild understands the dependancies, it can do intelligent build caching. eg if there were new changes in the libvirt SCM repo, but none in the virt-manager repos, it will still do a rebuild of virt-manager as a regression test
This new release version 1.2.1 was all about making the SCM checkout process more reliable. Previously if a module could not be checked out (eg due to a server being down, or a config file typo) the entire build cycle would be aborted. With the new release, the troublesome module is simply skipped and the SCM logs published for the admin to diagnose – other modules in the build cycle continue to be built