Planet Forge-FR

Hi.

I’ll be chairing the “development” track at the forecoming (10th edition) LSM/RMLL which will happen in July in Nantes (France).

I expect contributions about FLOSS development, so will soon push a formal call for contributions/communications, but here’s already the description of the track contents : Call for Communication concerning the “Development” topic of the 10th Libre Software Meeting (Nantes, France, july 2009) .

If you feel interested in co-chairing, I’d be glad to know

Pour info, le 21 janvier prochain aura lieu la prochaine rencontre de la communauté des forgerons francophones, dans le même esprit que la rencontre précédente de juin dernier.

Pour info, le descriptif complet de la rencontre prévue à La Cantine :

Rencontre francophone sur les forges logicielles libres à “La Cantine”, Paris le 21 janvier 2009.

Les forges sont des environnements Web permettant de répondre aux problématiques de développement collaboratif et distribué de logiciel.
Historiquement, les forges libres ont été popularisées par les plate-formes SourgeForge puis GForge. Aujourd’hui, un très grand nombre de projets utilisent des forges que se soit pour des développements libres ou open source ou pour des besoins internes en entreprise. Il existe actuellement de nombreuses initiatives de forges libres comme Trac, LibreSource, Codendi, Novaforge, Picoforge, Savane, ACOS, etc. Certaines sont dérivées de SourceForge ou Gforge, d’autres sont des implémentations spécifiques.
L’objectif des “Rencontres” est de permettre la concertation des utilisateurs et porteurs de solutions collaboratives pour identifier les besoins communs, les problèmatiques techniques et confronter des solutions possibles. L’objectif est ainsi de faciliter le travail de standardisation et d’échange entre les différentes forges en fonction des besoins réels exprimés par les utilisateurs.

La journée sera composée d’un mélange de présentations et de discussions pour s’intéresser de façon interactive à des questions comme:

• échange de données entre forges, interopérabilité
• définition d’un modèle d’intégration ouvert
• recherche multi-forges
• gestion des permissions et partage d’identités
• interaction entre la forge et le poste client

Cette journée s’adresse donc à tous les les acteurs du domaine des forges en France: chercheurs, industriels, utilisateurs, contributeurs ou fournisseurs de services.
Venez exprimer votre point de vue, échanger sur vos intérêts, besoins, solutions et bénéficiez du retour d’expérience des autres acteurs du domaine pour être informés des dernières avancées, définir une roadmap concertée ou travailler sur des formats communs.

Plus d’infos:

• Web: http://wiki.planetforge.org/index.php/
• Liste de diffusion des développeurs de forges francophones:https://picolibre.int-evry.fr/wws/info/forges

Weller, Martin J. and Meiszner, Andreas (2008) Report on the effectiveness of a FLOSS-like learning community in formal educational settings. Project Report. The Open University, Institute of Educational Technologies - UK, Milton Keynes, UK. From http://flosspapers.org/382/.

I’m passing the word about the OpenForge initiative whose goal is apparently try and foster interoperability between forges. Thanks to Nicolas Guerin for the pointer.

Great, I’ll keep an eye on that.

Excerpt from http://openforge.info/ :

OpenForge is an API (Application Programming Interface) that allows different development forges to communicate with each other. All the work is focused on interoperability. With this API, you can imagine a lot of features based on the aims:

* retrieve project’s datas
* retrieve user’s datas
* search for a user or a project

Quite similar to ideas entertained at wiki.planetforge.org

We’re hiring a software engineer, for 15 months, to work on bugtrackers synchronisation

(see full version of the offered job description here — et une version en français également : ici)

We’re looking for a software engineer to join our PFTCR team, in order to complement our R&D manpower on the HELIOS project. We’re responsible for a work package whose goal is to study and implement a system which would fit in the HELIOS platform, to ensure synchonisation between bug-trackers.

The workplace would be here in Evry (France, Paris area) for a duration of 15 months, under a french CDD contract (starting first quarter of 2009). The development done during the work on this project will be contributed back to FLOSS projects.

Strong know-how in software development as well as interest for research issues are expected from the candidates. Also, a good knowledge of the open source development tools, and of the dynamics of the libre software development communities is expected (distributions, packaging, QA). A practical experience of contribution on an open source project would be a plus (typically as Debian developper, for instance).. Technical english skills will be required (as well as notions of french, considering the french nature of the environment).

If you’re interested and available early 2009, I definitely want to hear from you.
See more details in full version of the offered job description.

There will be some interesting content (I hope) about forges at the forecoming Open World Forum, on the first days of december, in Paris. Besides the higher education track I already blogged about, the Qualipso project organizes its second conference during the forum.

There should be some presentation of the first results of the Qualipso forge, so I’m expecting interesting things to be shown and fruitfull discussions.

The OSOR project will be around also, and some participants of our french community of forgerons, and contributors to the planetforge aggregator.

Looking forward to meet you there.

Part of our work in the Helios project will be on bugtrackers synchronisation.

I happened to notice that bts-link’s maintainer called for help, which triggered more interest in that tool.

I’ve started working on bts-link to see how it works (cool, it’s Python and if it can be useful for Helios, and started implementing GForge tracker support in bts-link. That should help keep track of Debian bugs wrt upstream bugs for projects hosted in GForge forges (like Sympa, for instance, whose bugtracker is hosted in SourceSup).

You may find my git repo at http://www-public.it-sudparis.eu/~berger_o/git/bts-link.git which hopefull contains my proposed changes (I’m new to git, so I hope I did everything right…).

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.

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.

We’re seriously considering switching from phpGroupware to eGroupware for some infrastructure needed for a picoforge-based platform that we need to deploy soon.

phpGroupware is unfortunately kinda dead these days, whereas eGroupware seems to have managed to keep some momentum.

Of course we had preferred keeping with phpGroupware when the two projects initially switched apart, in particular because the GNU project-linked QA/copyright policies were a guarantee that our contributions may be better protected in such a collaboration environment (we tried and help the phpGroupware as much as we could, btw, and parts of this history is told when looking at : http://www-public.it-sudparis.eu/~berger_o/weblog/tag/phpgroupware/).

But the copyright policy is not all about successful collaboration, and it happens that phpGroupware fails to deliver from quite a few months now. Btw, I’m not so close to the project to tell exactly what’s happening and why, but looking at the mailing-lists, at least, the situation looks very bad.

So I dare say it lound : the phpGroupware project is quietly dying (at least from my point of view).

But as we need some improvements that were initially planned for its 0.9.18 release (filemanager, accounts, various stuff I’m not really qualified to list completely)… we need to consider what the options are…

And fortunately, it looks like eGroupware has not forked in a too much differing way, from a technical point of view, and that they have even improved some of the things we expected to be coming from phpGroupware 0.9.18.

So it’s very much likely that we’re going to try and switch to eGroupware for some parts of the platform to be deployed in the next month.

This may not concern the whole of the PicoForge infrastructure but only a particular project that builds on top of the current PicoForge infrastructure, with some variations.

As for the future of PicoForge as the libre software forge, it’s not really clear what’s gonna happen, but I think that we may be making a more radical switch some day, for instance by forgetting the old legacy PHP code, and so neither depending on phpGroupware nor eGroupware, but using some more modern tools/frameworks (and why not something like Tine 2.0 ? … no, but we may be inspired by some of its characteristics ;).

Qui vivra verra.

We have presented a paper at the WopDasD 2008 workshop (right after the OSS 2008 conference) in Milano, explaining how RDF could be used to propagate semantically tagged information from the forges to the “repositories of repositories” collecting facts on open-source projects, and advocating to tighter integration of the forges and the research analysis tools.

I was glad that another presentation was made by Kevin Crowston for a paper written by James Howison about the use of RDF semantic schemas to bring more interoperability between the various repositories of repositories (Update 2008/09/22 : slides here). Btw, they explained what RDF is in the slides just before me, so I got more time to talk about the rest

Also quite interesting was the presentation made by Andrea Wiggins for their paper about the workflow for scientific analysis in these repositories of repositories. I guess there’s some momentum towards more interoperability and more integration here. Maybe some web services could interoperate between what’s on the forges and what’s on the repository of repositories.

Weller, Martin J. and Meiszner, Andreas (2008) Report on the effectiveness of a FLOSS-like learning community in formal educational settings. Project Report. The Open University, Institute of Educational Technologies - UK, Milton Keynes, UK. From http://flosspapers.org/382/.

We have setup a collaborative maintenance project named pkg-cas for Debian.

The goal is to have more packages available in Debian to be able to use the CAS SSO (Single Sign On) framework for web applications.

More details at : http://wiki.debian.org/Teams/DebianCASPackaging

Feel free to join !

We’ve been setting-up the codename HELIOS project, together with other partners (lead by Thales), which got funded recently, as part of the pôle de compétitivité System@tic (libre software thematics).

That means that our PFTCR team at Institut TELECOM will be able to do more research around infrastructure and process of production for libre software projects.

Among the things we’ll focus in particular in this 2 year project, is the topic of traceability between bugtrackers (WP3). This topic seems quite interesting to many people I’m talking to at the moment in libre software projects (as discussed recently at RMLL/LSM) : good

I hope we’ll be able to help improve the current state of the art where lots of manual synchroniation is done in libre software (between upstream bugtrackers and distributions’ ones, for instance), and deliver useful tool to the communities.

We’ll keep you posted as the project moves on (scheduled kickstart september 2008).

For more details (in french), you may see the brochure (page 4) at System@tic’s site.

Update 2008/09/17 : here’s the official description of the project we’ve just drafted :

HELIOS is a project related to the System@tic research cluster. The aim of the project is to provide an Open Source ALM (Application Lifecycle Management) portal allowing to test, integrate, configure and maintain the many components of an application. HELIOS must be flexible and extensible enough to adapt to any tool with limited developpements in order for the users to keep on using their own tools. In the same way, flexibility and extensibility should allow services providers to build commercial offer. Most of existing ALM tools are specialised into one particular field (requirements management, qualification, project management, …) but the HELIOS project will aim at providing a complete platform covering activities from qualification to maintenance.

deliverable D7.2.1 of the qualipso project, documenting the state of the art for forges

 Bookmark this on Delicious - Saved by olberger to forge SoftwareForge qualipso gforge - More about this bookmark

Agrégateur de feeds sur les forges

 Bookmark this on Delicious - Saved by olberger to SoftwareForge forge - More about this bookmark

Site de ressources sur les forges logicielles

 Bookmark this on Delicious - Saved by olberger to SoftwareForge forge - More about this bookmark

Forge based on GForge and other tools

 Bookmark this on Delicious - Saved by olberger to SoftwareForge forge gforge - More about this bookmark

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.

Je m'aperçois que quand je cause d'outils de suivi de version, il m'arrive de mentionner, en plus des standards (CVS, Subversion, Bazaar et les autres), le vénérable CPOLD. Et que souvent, mes interlocuteurs ne connaissent pas CPOLD. Et effectivement, ce n'est guère documenté dans la littérature et le web multimédia mondial. Je m'en vais donc vous présenter un peu cette formidable méthodologie de suivi de versions.

Pourquoi formidable ? Parce qu'elle ne souffre d'aucun des problèmes récurrents des autres outils :

• pas de format de fichier complexe et susceptible de corruption ;
• pas de conflits ;
• aucun besoin d'un serveur dédié (on peut tout mettre ensemble, prod et dev confondues) ;
• aucune limitation sur la gestion des branches ;
• une rapidité insurpassable ;
• une simplicité de mise en œuvre et d'apprentissage enfantine ;
• pas de modèle de développement imposé (centralisé, distribué, en quinconce, en hélice, toutes les variantes sont possibles) ;
• des sauvegardes facilitées ;
• etc.

Pour résumer, CPOLD, c'est la poudre verte du suivi de versions. Mais alors, comment ça marche ? Très simplement. Tout répertoire contenant des fichiers est déjà une archive CPOLD, pas besoin d'initialiser quoi que ce soit. Pas besoin non plus de « prendre la main » sur un fichier avant de l'éditer. Une seule commande à retenir, celle pour créer une nouvelle version de ce fichier :

cp fichier fichier.old

Bien entendu, le .old peut être remplacé par n'importe quel suffixe ou combinaison de suffixes, il suffit de définir une convention de nommage et de s'y tenir. On pourra ainsi avoir fichier.old.test.2, la troisième révision archivée de fichier dans une branche « test ». Ou, lorsque les contraintes sont moins marquées ou moins fortement ressenties par l'équipe de développement, on pourra être moins strict. Un « dépôt » CPOLD pourra alors se présenter sous la forme suivante :

roland@mirexpress ~/cpold-demo $ ls
fichier                    fichier.OK             fichier.old.old
fichier.1999-08-16         fichier.old            fichier.old.test-roland
fichier.2003-10-27.valide  fichier.OLD            fichier.prod
fichier.a-verifier         fichier.old.marchepas
roland@mirexpress ~/cpold-demo $

Alors évidemment, ce système présente quelques inconvénients, dus principalement à sa simplicité. Mais il reste tout-à-fait utilisable dans des environnements de production, j'en veux pour preuve le nombre d'entreprises qui ne jurent que par lui et n'en changeraient pour rien au monde. CPOLD, le premier outil de suivi de versions du monde, est sans doute aujourd'hui encore parmi les plus utilisés. Il a su s'adapter depuis les copies de bande magnétique à bande magnétique, a vécu son heure de gloire à l'époque des disquettes, et continue vaillamment son aventure (avec un potentiel décuplé) à l'heure des mémoires Flash et de l'Internet.

Bon, ceci dit, personnellement je préfère Bazaar, et je ne mentionne pas CPOLD parmi les services que je propose habituellement à mes clients (si ce n'est pour leur proposer une migration depuis CPOLD vers autre chose).

Interesting approach to forges as mashup

 Bookmark this on Delicious - Saved by olberger to forge SoftwareForge - More about this bookmark

liste forges@picolibre.int-evry.fr

 Bookmark this on Delicious - Saved by olberger to forge SoftwareForge - More about this bookmark

Interesting project to help build NextGen Social Networks, and which may be usefull for Next Gen forges

 Bookmark this on Delicious - Saved by olberger to contrib2 SoftwareForge forge - More about this bookmark