Le weblog entièrement nu

This is getting old news, and others have blogged about them before I did, but here's my summary of the recent activity in and around FusionForge.

The early February meeting was a success, and gathered about twenty people on the first day and a dozen or so on the second day (not planned initially). My impression is that there was a healthy mix of FusionForge hackers, FusionForge users, and people from other forge communities (Codendi, NovaForge, and even one representative from nFORGE, from South Korea). I'm not going to repeat all that was said then, especially since the proceedings are online. Beyond the technical points, I'll just advertise PlanetForge again, since everyone present agreed we had lots to share and that this site would be a good and relatively neutral place. If you're into forges, I recommend joining us in that community.

On the purely FusionForge front, news are good too. Most of the major pieces we want to see in the next release (which is probably going to be called 5.0) are in place. The last blocker we had was the merge of the rework of the default theme for better accessibility and easier maintenance and customisability (most of the theming now happens in CSS). This merge has been completed this week, and although there are still a few rough edges, it's mostly done. We'll try to fix most of these rough edges soonish, then start a stabilisation branch towards 5.0, so more experimental work can start again on trunk. For the impatient and the curious, there's a list of new features on the fusionforge.org homepage, and the site is now running code from trunk.

Of course, we're eager to get testers for that, which is why I prepared snapshot packages. They are currently stuck in NEW on their way to the official Debian experimental repository due to the renaming of the source package and the introduction of plenty of new binary packages, but they can already be obtained from my unofficial repository at people.debian.org. The packages are built for Debian unstable, but they seem to run just fine on Lenny if you grab mediawiki from backports (only required for the Mediawiki plugin, of course), and libnusoap-php and php-htmlpurifier from Debian testing (they don't drag any extra dependencies).

I'll end this note by reminding people of the announcement I did three months ago: as of this week, Debian Etch is no longer officially supported security-wise, and so neither is GForge 4.5. As far as I know, I was the last person doing that, and my incentives have gone away on the day Etch ceased to be supported, since it was also the day the Adullact forge finally migrated from Etch with GForge 4.5 to Lenny with FusionForge 4.8. If you're still using 4.5, well… I think you should be aware of that.

That more or less wraps it up for now. The next announcement is likely to be about a release candidate…

I normally don't relay security announces for GForge or FusionForge on this blog, but I will make an exception this time: Alain Peyrat found several places in the code with insufficient input sanitizing, which can cause cross-site scripting vulnerabilities (CVE-2009-3303). It's been fixed in the 4.7 and 4.8 branches as well as the trunk of FusionForge (and in Debian Sid and Squeeze), and updated Debian packages for GForge 4.5 and 4.7rc2 have been released for users of the Etch and Lenny distributions.

The reason I make an exception for announcing this here is to remind people that I appear to be the only one maintaining code for GForge 4.5. I do that for two reasons: first, because I'm the maintainer of the package in Debian, and Debian Etch has GForge 4.5, and Etch is supported for security fixes; second, because I also admin/maintain an instance for a client of mine, so I need to backport the fixes anyway, and making them public is no bother. Both of these reasons are going to vanish sometime in the not too distant future: security support for Etch will end in February, 2010, and I hope to have migrated my client's forge to FusionForge 4.8 by then too. A direct consequence is that I will probably stop maintenance for GForge 4.5 in the coming months (at least I'll stop doing it in my free time).

So if you're still using GForge 4.5, you should really consider upgrading to something supported, either GForge AS (free download from the GForge Group) or FusionForge (free as in Free Software). Both have an upgrade path. Obviously I think FusionForge is a better choice, but my position is probably biased.

(Ceci est juste un résumé en français de l'annonce complète en anglais.)

Au début, il y avait SourceForge, un logiciel libre développé par une boîte qui s'appelait (à l'époque) VA Linux Systems. Ce logiciel était utilisé par plein de gens, et développé de manière plus ou moins collaborative. Un jour, VA Linux Systems a décidé que les nouvelles versions de SourceForge (à partir de la version 3) ne seraient plus libres (et qu'elles s'appelleraient Sourceforge Enterprise Edition). Plusieurs personnes sont donc parties avec la dernière version libre (celle qui aurait pu devenir la version 2.6), avec dans l'idée de maintenir ce code.

Il y a donc eu GForge, un logiciel libre développé entre autres par une boîte qui s'appelle le GForge Group. Ce logiciel était utilisé par plein de gens, et développé de manière collaborative, notamment par votre serviteur. Un jour, le GForge Group a décidé que les nouvelles versions de GForge (à partir de la version 5) ne seraient plus libres (et qu'elles s'appelleraient GForge Advanced Server). Mais comme l'hébergement du projet était maintenu ouvert, les versions 4.x ont pu être maintenues de manière libre et collaborative.

Pendant ce temps, l'appellation "GForge Advanced Server" s'est faite de plus en plus rare, et des noms plus équivoques sont apparus : "GForge AS", "GForge Express Edition" (ou "GForge EE") et, plus récemment, "GForge Community Edition", aucun de ces logiciels n'étant libre (même si certains sont disponibles en téléchargement gratuit et qu'on peut même jeter un œil aux sources).

Comme cette ambiguïté prêtait à confusion (certains utilisateurs ont installé une version propriétaire en croyant installer un logiciel libre), les principaux développeurs de la version libre de GForge (Christian Bayle, Alain Peyrat et moi-même) ont décidé de... partir avec le code, et de renommer le projet de développement et de maintenance de ce code libre.

Le résultat s'appelle FusionForge, et il est hébergé sur FusionForge.org. Nous avons plein d'idées, mais un des buts majeurs (qui a justifié le nom) est que nous allons chercher à réintégrer dans le code commun des fonctionnalités qui ont été développées localement par des utilisateurs mais non publiées. Ça tombe bien, nous sommes déjà en relation avec plusieurs de ces utilisateurs institutionnels qui semblent intéressés par cette convergence.

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

Stuff happens quietly on the GForge front, but after some time we decided we're getting bored with not releasing. Since we seem to have run out of major problems in the codebase, the long-awaited GForge 4.7 release is probably round the corner.

And so, since GForge migrated from its own in-house translation system to the more conventional gettext API, I'd like to take the opportunity to issue a call for translations, knowing that potential translators won't be too disturbed by unusual tools and formats.

You can grab the current state of the translations from the GForge repository browser. Or, for more long-term involvement, checkout the code through Subversion or through Bzr (my gateway branch is available from bzr.debian.org. Current statistics are as follows:

• bg.po: 382 translated messages, 174 fuzzy translations, 1813 untranslated messages.
• ca.po: 1592 translated messages, 281 fuzzy translations, 496 untranslated messages.
• de.po: 1627 translated messages, 272 fuzzy translations, 470 untranslated messages.
• el.po: 0 translated messages, 2369 untranslated messages.
• eo.po: 0 translated messages, 2369 untranslated messages.
• es.po: 1600 translated messages, 236 fuzzy translations, 533 untranslated messages.
• eu.po: 1392 translated messages, 272 fuzzy translations, 705 untranslated messages.
• fr.po: 2368 translated messages, 1 untranslated message.
• he.po: 0 translated messages, 2369 untranslated messages.
• id.po: 0 translated messages, 2369 untranslated messages.
• it.po: 1781 translated messages, 303 fuzzy translations, 285 untranslated messages.
• ja.po: 246 translated messages, 118 fuzzy translations, 2005 untranslated messages.
• ko.po: 1292 translated messages, 264 fuzzy translations, 813 untranslated messages.
• la.po: 0 translated messages, 2369 untranslated messages.
• nb.po: 0 translated messages, 2369 untranslated messages.
• nl.po: 1621 translated messages, 287 fuzzy translations, 461 untranslated messages.
• pl.po: 0 translated messages, 2369 untranslated messages.
• pt_BR.po: 1292 translated messages, 262 fuzzy translations, 815 untranslated messages.
• pt.po: 0 translated messages, 2369 untranslated messages.
• ru.po: 302 translated messages, 142 fuzzy translations, 1925 untranslated messages.
• sv.po: 1289 translated messages, 261 fuzzy translations, 819 untranslated messages.
• th.po: 0 translated messages, 2369 untranslated messages.
• zh_CN.po: 1691 translated messages, 300 fuzzy translations, 378 untranslated messages.
• zh_TW.po: 1664 translated messages, 289 fuzzy translations, 416 untranslated messages.

Results as patches to our patch tracker or the gforge-devel ML please.

(Note to Debian-related readers: this translation work will be directly useful on Alioth when we upgrade it.)

J'ai l'immense honneur de figurer dans les pages de l'illustre magazine 01 Informatique de cette semaine, dans un encadré en marge d'un article sur les forges déclenché par une actualité (Sun a sorti une forge). Wouhou, c'est la gloire, je suis devenu un people et les statistiques de fréquentation de mon site pro autant que de ce blog vont exploser, et je vais être courtisé par les décideurs qui lisent 01 !

Je saisis donc l'occasion pour apporter quelques rectifications à cet article de Yann Serra.

• Ne vous fiez pas au titre de l'encadré (« 2 questions à Roland Mas »), ni aux guillemets : il ne s'agit pas de questions qui m'ont été posées, ni encore moins de citations de mes réponses.
• Apparemment je n'ai pas assez insisté lors de l'entretien téléphonique sur le fait qu'une forge est une plate-forme collaborative, pas juste un site de téléchargement. Du coup, la première question perd tout son sens (ce qui explique que la « réponse » supposée soit confuse.
• Sur la deuxième « question »... la réponse qui m'est attribuée ne répond pas à la question, et pour cause : Sun n'a jusqu'à présent fait que des annonces sur ce qui différencie Kenai des autres forges. “We're more than just a forge”, mais on ne sait pas quoi. “More about these features will be revealed as we get closer to their availability.” Difficile donc de juger sans savoir.
• Je n'ai pas non plus assez insisté sur l'aspect Ruby, visiblement. Ma position là-dessus est que les choix d'implémentation de Kenai n'ont pas la moindre espèce d'importance sur le succès de la forge kenai.com tant qu'elle est uniquement hébergée par Sun. Ce serait du Cobol ou de l'Intercal que ça ne changerait rien. Ils ne deviendront pertinents que si le logiciel Kenai est publié sous une licence libre, parce qu'ils constitueront, ou non, des barrières à l'entrée pour des contributeurs potentiels qui feront vivre la communauté.

Je ne crache pas sur le journaliste, ç'aurait pu être bien pire. Je suis juste déçu que mes propos aient été complètement réinterprétés, et je déplore ouvertement que l'article laisse entendre que Sun ait relancé une quelconque bataille, alors que pour l'instant rien ne différencie dans le bon sens Kenai d'une autre forge.

Mais bon, je suis un people, il faut que je m'y habitue, pour être préparé le jour où on me fiancera à Grace Kelly ou à la Castafiore. En attendant, vous pouvez trouver des paquets Debian de GForge sur http://people.debian.org/~lolando/. Avec les autres people.

Quick status update: not much happened due to a variety of reasons, but there is still some progress to report.

The most important piece of news is that the Mediawiki plugin should be on its way to Debian sid by the time you read this, as the new gforge-plugin-mediawiki binary package (it'll have to go through NEW, but that seems to be rather fast these days). Testing and reporting and bugfixing are most welcome, of course.

I also went through a round of cleanups in the packaging. No more Lintian overrides, far fewer Lintian errors and warnings, and some fixes for PostgreSQL 8.3 compatibility.

Voici quelques nouvelles de GForge en français, pour changer, parce qu'il y a visiblement un fort contingent d'utilisateurs francophones de GForge. Si le blabla ne vous intéresse pas, sautez quelques paragraphes, y'a une annonce qui peut vous intéresser.

Je m'en doutais un peu à vrai dire : je savais déjà qu'il y avait des instances de GForge en usage dans un certain nombre d'entreprises et d'administrations françaises. Je déplorais d'ailleurs que ces usages soient privés, voire secrets... On n'en entendait parler que par la bande, au détour d'une conversation. Et chacun avait ses bricolages locaux, et ses améliorations personnelles, dont personne ne profitait.

Heureusement, les différents utilisateurs francophones de GForge (de forges en général) ont fini par plus ou moins se retrouver, et des discussions ont commencé sur la liste Picolibre Forges. On s'aperçoit donc que de nombreux utilisateurs existent, qu'ils ont souvent des besoins communs, et que certains ont même déjà des solutions à apporter à certains de ces besoins. Il se pourrait bien que ces utilisateurs (et ces développeurs) se mettent à communiquer et à relancer une vraie dynamique de communauté autour de GForge (pour l'instant, il y a une poignée de développeurs, et quelques utilisateurs qui ne communiquent pas, donc j'hésite à appeler ça une communauté). Quelques-uns de ces utilisateurs et moi-même nous sommes rencontrés à la conférence Qualipso la semaine dernière, normalement nous devrions nous retrouver au salon Solutions Linux la semaine prochaine, et une réunion spéciale forges est même organisée après ça. Donc, ça prend forme.

Concrètement, ce que j'espère principalement est que les modifications de chacun seront partagées, de sorte qu'elles puissent être intégrées au cœur de GForge, et portées sur une version plus récente (puisque l'immense majorité des utilisateurs actuels sont basés sur une version 4.5.x patchée). Le « tronc » Subversion de GForge devrait donc intégrer, dans un futur que j'espère pas trop lointain, les évolutions suivantes :

• Intégration du bug-tracker Mantis : au moins deux (et vraisemblablement trois) entités ont déjà réalisé cette intégration, et j'essaie de récupérer les patches pour que tout le monde en profite. Pourquoi tout le monde se focalise sur l'intégration d'un nouveau tracker au lieu d'exploiter la flexibilité de celui de GForge pour l'étendre, ça me dépasse, mais je ne suis pas là pour juger. De même, je trouve vraiment dommage que ce développement ait été fait deux ou trois fois de manière indépendante et sans concertation. Vous avez dit gaspillage de temps humain ?

• Ajout d'un système d'intégration continue (on me dit « Maven »). Là encore, normalement ça a déjà été fait, il ne devrait plus rester qu'à publier les patches et les porter vers l'état actuel du code.

• C'est peut-être lié à l'item précédent (je manque de détails), mais on devrait aussi voir apparaître une intégration dans GForge d'un système de tests automatisés.

...et je ne doute pas que d'autres utilisateurs, qui ont eux aussi ajouté leurs propres fonctionnalités sans rien dire à personne, vont aussi se révéler au grand jour et collaborer avec la communauté (n'est-ce pas ?). Peut-être même que des gens vont remettre au goût du jour l'empaquetage RPM, abandonné depuis plusieurs années.

Histoire de ne pas être en reste, je fais ici l'annonce publique suivante : le plugin Mediawiki pour GForge est enfin publié. Ce plugin fait suite à une intégration faite « avec des contraintes de temps assez serrées » (comprendre « un peu à l'arrache ») pour un client, et à une autre intégration faite plus proprement pour un autre client. Le dépôt SVN de gforge.org contient donc présentement le code qui va bien, et la prochaine version des paquets Debian qui seront publiés fournira un nouveau paquet binaire appelé gforge-plugin-mediawiki. Je dispose également d'une version du plugin pour GForge 4.5.x, mais comme Mediawiki nécessite PHP 5, il faut également extraire de ma branche client la conversion PHP 4 → PHP 5 de GForge 4.5 (et en retirer les fonctionnalités réellement spécifiques au client), ce qui explique que ce n'est pas encore publié sur mon dépôt APT (ni déployé sur Alioth). J'y travaille, promis.

First, and most important: while researching a functional bug for a client, I found a rather important security problem in GForge. All versions (starting from 3.1) are vulnerable to an SQL injection problem due to missing input sanitisation. Debian packages have already been fixed and released, and the patches have been committed to the upstream Subversion repository, so non-Debian users are encouraged to grab the patches from there. For instance, the patches for the 4.5.* branch can be obtained from the ViewVC page. For reference, the CVE ID for this problem is CVE-2008-0173.

Secondly, there's a new "gforge" tag on this blog, to filter posts that relate to GForge. I mainly created it in response to the existence of a feed aggregator focusing on forges and variants, but you can also subscribe to it directly if you only want to hear about Gforge and not about my other Free Software activities. I'll also use it to announce security patches like this one.

I'm on a roll...

• Gettext transition is fully done now (old functions have even been removed).

• French translation 100% complete! Woo!

• Packages now use ucf. So there.

• Installation process streamlined: if you just want the web interface, you'll only need to aptitude install gforge-web-apache2, and the only interactions it'll require are to type the admin password (twice) and to accept (or integrate by hand) a change in the PostgreSQL config file.

• It even works on Debian GNU/kFreeBSD!

Plans for the near future include continuing to clean up upstream code and maintainer scripts, making sure the installation process is as simple as possible (even for other subpackages), splitting out a few plugins into their own packages. And the big placeholders-in-prepared-SQL-queries audit I mentioned last time, but it may happen progressively rather than in one big go.