This is my monthly summary of my free software related activities. If you re among the people who made a donation to support my work (84.25 , thanks everybody!), then you can learn how I spent your money. Otherwise it s just an interesting status update on my various projects. Debian Packaging In one of my customer projects, I had to use libwebsockets and since it was not packaged for Debian, I filed a Request For Package (RFP #697671). I discovered a fork of this library on github and decided to mail the original author and the author of the fork to learn a bit more about the reason of the fork. It turns out that they miscommunicated and that the original author was interested by most of the improvements. The fork still exists but the important fixes and most of the improvements have been merged (and he released a version 1.0 after that!). Furthermore the original author setup a bug tracker to better organize the project and so that the author of the fork can submit patches and be sure that they won t be forgotten (as it happened in the past). I spend quite some time discussing with both parties but at the end I m pleased to see that good progress has been made (although nobody stepped up to maintain this package in Debian). I packaged zim 0.59 (an important bugfix release) and wordpress 3.5.1 (with several security fixes). I updated the dpkg-dev squeeze backports to version 1.16.9~bpo60+1 on request of Daniel Schepler. This backport led me to file #698133 on kgb-client because the bot literally spammed the #debian-dpkg IRC channel for multiple hours by resending old commit notices that got merged in the squeeze-backports branch. BTW, they need help to get this issue fixed. I updated python-django-registration to fix a compatibility issue with python3-sphinx (see #697721 for details). Misc Debian Stuff Serious bug with salt. I filed a grave bug on salt (#697747 ) and prepared the upload to fix the issue on request of the maintainer. In the mean time, the maintainer orphaned the package. Franklin G. Mendoza already announced its willingness to take over but this package deserves multiple maintainers since this is a good piece of software that is getting more and more popular. net-retriever and alternate keyrings. I filed a wishlist bug (#698618) on net-retriever to request a way for derivatives to use another keyring package (i.e. not debian-archive-keyring-udeb) without having to fork net-retriever. Linux 3.7 on armel/armhf. I helped the kernel maintainers to fix the 3.7 kernel on armel/armhf by reporting on IRC the results of successive failing kernel rebuilds on those architectures (this kernel version is only in experimental). Carl9170 firmware. I also pinged the kernels maintainers about a missing firmware for the carl9170 driver (already reported in #635840) and Ben Hutchings took care of re-activating its inclusion in upstream s linux-firmware.git and then uploaded firmware-free 3.2 to Debian. Thanks Ben! New QA team member. And to finish with the miscellaneous stuff, I helped Holger Levsen to be added to the qa group so that he could integrate his awesome work on automated QA checks with Jenkins. Debian France Preparation for Solutions Linux. The people organizing the village of associations in the Solutions Linux conference have asked all organizations to apply for a booth if they wanted one. Last year Carl Chenet took care of organizing this and this time we had to find someone else. I made multiple call for volunteers (on the mailing list, on my blog) without much success but I finally managed to convince Tanguy Ortolo to take care of this. Thank you Tanguy! Get in touch with treasurer who disappeared. During the transition with the former Debian France officers, it has been said that Aur lien G r me another former treasurer of Debian France had entirely disappeared together with some papers that he never gave to his successor. I didn t want to give up on this without at least trying to get in touch by myself so after multiple tries (over IRC, phone, and snail mail), and some weeks without answers, he got back to me, explaining that he s currently in a foreign country and that he will take care of that next time that he comes in France. \o/ New website in preparation. Replacing the single-page website webpage with a more comprehensive website is an important goal. Alexandre Delano provided a basic ikiwiki setup inspired by dsa.debian.org. I cleaned it and integrated it in a git repository on our machine. There s thus a new test website on http://france.debian.net/test/. Tanguy Ortolo and Fernando Lagrange immeditaly made some small improvements but since then nobody stepped up to further complete the website. I ll try to do this in February and put the new website in production. Paypal and handling of members. We installed a paypal plugin in galette so that members can renew their membership online. I asked Christian Bayle to try it out and we found some issues that I reported upstream and that got fixed. But this is only the first step, we want to go much further and automate all the membership handling, from membership renewal mail reminders up to integration in the accounting system. To this end, I filed some new tickets in the Galette tracker and completed some that were already opened: #490, #368 and #394. We requested a quote for those tickets and Debian France is going to fund the work on those tickets so that we have a 100% free software solution for our needs. Thanks See you next month for a new summary of my activities.

No comment Liked this article? Click here. My blog is Flattr-enabled.

Executive summary To avoid confusion with the proprietary versions of GForge (known as GForge Advanced Server, GForge Express Edition and GForge Community Edition), the free/libre/opensource codebase will from now on be separately maintained under the name FusionForge by the main developers of the free GForge 4.x codebase. Since this is mostly a renaming, the migration path for existing users will be smooth. Longer version, with details After the initial forking from the Sourceforge codebase, the development of GForge has long been hosted, and many enhancements directly developed, by the GForge Group (GForge, LLC), with regular contributions from outsiders. The results of these evolutions were public and free, subject to the GNU GPL. In parallel, the GForge Group wrote a proprietary re-implementation of GForge, which it sold under the name "GForge Advanced Server", or "GForge AS" for short. This re-implementation added some features for "the enterprise", but was not contributed wholesale to the GForge codebase under a free license. Although some of the features were contributed to the public, the GForge Group concentrated its efforts on its (proprietary software) business model, with more versions appearing, such as "GForge Express Edition" and more recently "GForge Community Edition". As a result, it became increasingly harder for the public to know which version was which without doing extensive research (indeed, some users mistakenly installed one version instead of the other). A consequence was that the free software codebase suffered from a loss in visibility, which lowered its momentum to the point that there haven't been any moderately important releases since the (currently stable) 4.5.x series was announced in late 2005. So, in order to clarify things, avoid further confusion, and regain some of the lost momentum, it was decided by a group of leading contributors that the free software version of the GForge codebase would from now on be developed under the FusionForge name, and its development would be hosted on FusionForge.org. So is this a fork? Well, we don't know yet. It could arguably be called one, since we're taking the code and running away with it under a new name. However, we believe it's not a fork unless both roads continue their own way (more of a oddly-shaped bend). What happens to the GForge codebase developed by the GForge Group at gforge.org remains to be seen, although for the sake of our users we will backport security fixes to the gforge.org Subversion repository (at least for the 4.5.x series and the unreleased 4.6 and 4.7 pre-series) for some time. The bulk of the development will move on to FusionForge and the repositories at FusionForge.org, though, and users are encouraged to migrate at their own pace. Since we're basically continuing the evolution rather than starting from scratch, the migration path should be rather smooth. So why the FusionForge name? Because there were actually lots of locally-patched versions of GForge (and Sourceforge), and we felt it was a waste of resources that should be fixed. It seems many people and organisations took these codebases at some point in time and evolved them for their own needs. Sadly, many of the changes were not contributed back or even published, so lots of efforts were duplicated. Fortunately, many of the people managing these locally-patched forges are now realising that "out-of-tree" patches and features require quite some manpower to maintain. Some formal inter-project discussion is already taking place, and we hope to achieve actual merging of most of the interesting features that have been developed here and there into a common base that can be reused locally with minimal changes. We'd like to "un-fork" as much as possible. We also expect that, by using standard components and tools, we'll facilitate the work of potential contributors, thereby reducing the risk of a new era of fragmentation. And who are we anyway? We're Christian Bayle, Roland Mas and Alain Peyrat, long-time contributors to GForge and responsible for over 95% of the commits over the past two years, as well as a few relative newcomers. Christian and Roland have been maintaining the Debian packaging since the "Debian-SF" era, and Alain has been focusing on code quality. The three of us have, for various reasons, a vested interest in maintaining a lively codebase in a healthy ecosystem. What are our plans? Our short-term goals, as currently planned, include:

• pushing a stable FusionForge release out of the door;
• cleaning up and auditing the database schema to ensure consistency and increased performance;
• merging in new plugins, in particular for new version control systems;
• continuing streamlining the installation process to make it more portable across distributions.

Longer term goals are less well defined, but we're thinking about the following:

• increasing code quality by the use of modern automated tools;
• encouraging a lively stream of external contributions, to reduce the gap between the official version and the locally-patched ones;
• defining an explicit governance model and release process for the FusionForge project;
• as a consequence, a more frequent and predictable release schedule;
• increasing data portability and interoperability with other forges, to reduce lock-in for users and projects.

Some of these items should be facilitated by our switch to a distributed version control system and a new coordinated workflow. Also, the Debian i18n team has been kind enough to offer to host our translation effort on their Pootle server, which means translators will have a much easier time doing their job. We hope to hear from users and contributors alike in the near future. For more information, we can be reached via our fusionforge-general mailing-list (see our lists), which is also suitable for general discussions. We can also be found on IRC (#fusionforge on the Freenode network).

...or, "Bits from a Gforge maintainer", if you'd like. After being neglected for way too long, the Gforge packages have finally started moving again. Packages for the most recent upstream release (4.5.14) are available in experimental, with quite a few improvements over the version currently in unstable:

• lots of improvements upstream, of course;
• no more sourceforge transitional package;
• source control management systems are now integrated via plugins rather than core code; existing plugins are gforge-plugin-scmcvs for CVS and -scmsvn for Subversion (both are in experimental);
• should support recent versions of PostgreSQL;
• default authentication scheme for users created through Gforge is now no longer LDAP (although it's still available for the masochistic); nss-pgsql is now preferred, with lots of benefits (not the least being that its configuration and setup are far less brittle);
• and lots more, thanks to Christian Bayle's work while I was busy doing something else.

From a Debian maintainer's point of view, my Gforge-related TODO list now mainly sports three items.

• First, rewrite some PHP code into Perl: the script in charge of bringing the database schema up-to-date, db-upgrade.pl, currently delegates some of its work to PHP scripts with system() calls. That's justifiable by the fact that these PHP scripts can use the Gforge code, classes and methods, but it makes the whole upgrading process fragile: for some reason, the system() calls sometimes fail without db-upgrade.pl noticing, and the process then just goes on with a broken DB instead of stopping right there with an error. Also, this is doomed to fail sometime: the Gforge classes used are the ones currently installed, which may or may not correspond to the database schema (remember we're in the middle of an upgrade, so the schema is moving). Since I want this db-upgrade.pl script to be unbreakable, I need to change that.
• In addition to that (or in parallel), I'd like to migrade the gforge packages to use the dbconfig-common infrastructure. It's supposed to be able to take on the tasks of database (and database user) creation, while still giving me a hook to plug db-upgrade.pl into.
• When the dbconfig-common migration is done, I'll probably spam^Wcontact the various translation teams, so the Debconf templates look good and consistent.

I suppose I could also try and migrate to the webapps-common framework, but I'll keep that for later. Of course, any help is welcome. Remember: the sooner I get the Gforge packages into a reasonable shape, the sooner they'll go to unstable, then testing, and the sooner I'll be backporting them to sarge, which means Alioth can be upgraded. But since I've heard a few complaints about Alioth being too damn slow or broken or whatever, I expect I'll get lots of patches (in bug reports, please) from disgruntled users eager to help.

…or, “Bits from a Gforge maintainer", if you’d like. After being neglected for way too long, the Gforge packages have finally started moving again. Packages for the most recent upstream release (4.5.14) are available in experimental, with quite a few improvements over the version currently in unstable:

• lots of improvements upstream, of course;
• no more sourceforge transitional package;
• source control management systems are now integrated via plugins rather than core code; existing plugins are gforge-plugin-scmcvs for CVS and -scmsvn for Subversion (both are in experimental);
• should support recent versions of PostgreSQL;
• default authentication scheme for users created through Gforge is now no longer LDAP (although it’s still available for the masochistic); nss-pgsql is now preferred, with lots of benefits (not the least being that its configuration and setup are far less brittle);
• and lots more, thanks to Christian Bayle’s work while I was busy doing something else.

From a Debian maintainer’s point of view, my Gforge-related TODO list now mainly sports three items.

• First, rewrite some PHP code into Perl: the script in charge of bringing the database schema up-to-date, db-upgrade.pl, currently delegates some of its work to PHP scripts with system() calls. That’s justifiable by the fact that these PHP scripts can use the Gforge code, classes and methods, but it makes the whole upgrading process fragile: for some reason, the system() calls sometimes fail without db-upgrade.pl noticing, and the process then just goes on with a broken DB instead of stopping right there with an error. Also, this is doomed to fail sometime: the Gforge classes used are the ones currently installed, which may or may not correspond to the database schema (remember we’re in the middle of an upgrade, so the schema is moving). Since I want this db-upgrade.pl script to be unbreakable, I need to change that.
• In addition to that (or in parallel), I’d like to migrade the gforge packages to use the dbconfig-common infrastructure. It’s supposed to be able to take on the tasks of database (and database user) creation, while still giving me a hook to plug db-upgrade.pl into.
• When the dbconfig-common migration is done, I’ll probably spam^Wcontact the various translation teams, so the Debconf templates look good and consistent.

I suppose I could also try and migrate to the webapps-common framework, but I’ll keep that for later. Of course, any help is welcome. Remember: the sooner I get the Gforge packages into a reasonable shape, the sooner they’ll go to unstable, then testing, and the sooner I’ll be backporting them to sarge, which means Alioth can be upgraded. But since I’ve heard a few complaints about Alioth being too damn slow or broken or whatever, I expect I’ll get lots of patches (in bug reports, please) from disgruntled users eager to help.