Forges Meeting February 2010 Proceedings

From PlanetForge

Jump to: navigation, search

Two interesting real-life meetings took place near Paris (France) from the 2nd to the 4th of February, 2010, both concerned with software forges:

  • Tuesday, February 2nd was the third internal COCLICO project meeting, with presentations of initial results and progress reports on other subjects.
  • Wednesday and Thursday, we had a gathering of some of the FusionForge developers and users, as well as a few other people representing other forge softwares (Codendi, nForge, NovaForge, etc.).

COCLICO internal meeting

Tuesday was an internal meeting for the COCLICO project (which, among other goals, aims at coordinating development efforts across a few forges, and agree on common concepts and targets so that new features can be developed once and be ported across forges with minimal effort). The project started four months ago, so it's far from having reached its objectives yet, but we had a progress report on some of the subprojects.

For instance, we've had a demonstration of a long-awaited improvement in the Mailman integration within FusionForge. That integration is currently minimal, but work is in progress to make it tighter, and the prototype developed within COCLICO already allows subscribing to and unsubscribing from mailing-lists, within the forge's web interface. More features are forthcoming, and the required patches (to FusionForge and Mailman) will be contributed upstream.

Another result that was demonstrated is a new interface that plugs into the tracker infrastructure and allows visual manipulation on bugs. The main objective for that is to accomodate agile development methods such as SCRUM, where tasks or defects can be manipulated easily with drag and drop, for instance. This prototype is currently developed on top of the Codendi forge.

Interchange formats and tools are also a goal of the project. Long-term plans involve dynamic interoperability between forges, whereby a project could theoretically be split across forges, with automated synchronisation happening when needed. We're not there yet, as the initial focus is on static interoperability, and the ability to dump (or export) a project from a forge, and to reload (or import) it again (possibly in a different forge running different software). This has similarities with what Eric Raymond started discussing (and then went on to implement on his own in the ForgePlucker project [1]), even though the motivation may be a bit different. There will probably be some collaboration with his Forgeplucker project, in order to re-use the framework and add the missing parts. One of the missing parts is the use of standard ontologies so that the dumps/exports can be used for unambiguous artifact identification (and semantic harvesting); also, having well-defined semantics for the various data means there's already a standard pivot, so importing the dump into another forge should be relatively straightforward.

Other topics that were discussed include the definition of a REST API for the trackers as a standard API, since based on OSLC-CM, so that interaction with trackers from other software (such as IDEs like Mylyn, or reporting tools, for instance) could work with no extra effort. The goal here is to have Eclipse be able to list, create, update and close items on different trackers with the same API/protocol, whether the items are bugs stored in a Bugzilla or artifacts in a FusionForge tracker.

These were just the highlights of the Coclico meeting. A more complete and formal summary will probably be pushed to the Coclico website when they're done.

FusionForge (and others) public meeting

The FusionForge meeting was also very interesting, one of the reasons being that there were a variety of people besides the FusionForge hackers themselves: there were developers from Codendi and NovaForge, of course (since Xerox and Bull, the companies behind these two forges are involved in COCLICO), but also from Evolvis, a FusionForge-based system developed by German company Tarent, and from nFORGE, a fork of the GForge 4.x codebase operated by NHN Corporation in South Korea. (Technically, PicoForge was also represented, but most of their development effort has shifted to FusionForge). There were also users and administrators of forges. This kept our discussions in a rather high level, which is good because it's probably going to foster collaboration between these forges. It also gives some more credibility to the theory that this forge thingy isn't just a French cabal.

As a concrete example: we discussed the upcoming revamping in the configuration system in FusionForge, and compared the way configuration settings are currently accessed by the various parts of the code in our forges, and we roughly agreed on a common API to do that. If (and when) all of us migrate to that API, not only will the code be cleaner and more readable, but that will also facilitate the sharing of plugins across forges, for instance, since the forges themselves will do whatever is needed (database access, configuration files, LDAP queries and so on), and the code of the plugin can rely on forge_get_config('section','forgename') to do the right thing. Also, having all calls to the configuration go through that API should allow formal consistency checks for the configuration settings. A prototype of the code is developped currently by Lo-lan-do for FusionForge.

We also discussed SSO and related topics, with a presentation of the Shibboleth identity federation system.

More generally, we had a confirmation of what we already suspected: even across the forks (we're all more or less descendants of the original SourceForge codebase), most of our concerns are shared, and sharing our experiences is going to help us all. This meeting is a good place for such discussions, but it's still hard to get everyone around a physical table, so we'll try to foster cross-forge collaboration subjects under the http://planetforge.org/ umbrella. PlanetForge is not the brand name for a new forge system, but a "community site" we want to promote as a reference place for forge matters. This should ensure a neutral place for developers of all forges to discuss evolutions, and I'm sure we all have something to gain from such discussions. The COCLICO project is a good first step, but since it's limited in time, scope and participants (and it's French-only anyway), we need to expand the cross-forge forum to something more open. There's already a http://wiki.planetforge.org/, and a recently created a "discussions" mailing-list at http://lists.planetforge.org/. We plan to bootstrap the process with a presentation of existing stuff (for instance, each forge team could describe the major changes that happened since their latest fork), and keep it running by announcing upcoming changes and discussing them beforehand.

We also took some time to discuss governance issues in FusionForge. If you recall the initial FusionForge announcement, one of the goals of the project was to have an explicit and transparent governance model. We have so far fallen short of that, and although we believe we are more transparent than we used to be, there's no formal decision-making process. So far, we haven't been facing a decision point where consensus wasn't reached, so maybe just acknowledging that could work; the motto of the IETF, after all, runs something like "We reject kings, presidents and voting; we believe in rough consensus and working code", and that could be a perfectly valid decision-making process. Maybe we just need to document who "we" are and where the consensus should be reached. More light "marketing" may not hurt though (improving our traces on ohloh.net for instance), since such effort would help present FusionForge as what it is : a project that allows mutualization of efforts of various professionals and companies, and not just a pet project from few geeks in a garage. The right balance of formalization and focus on code contributions is to be determined by the contributors.

Another topic we discussed was about the contribution process. It's currently a bit obscure, for both technical and social reasons. We're working on the technical reasons (by refactoring code so it becomes easier to read, write and maintain), but there also needs to be a simple, documented way of contributing: how to write contributions, who to contact about them, how to send the changes, how to get them reviewed and merged, and so on.

Interestingly, there's one point that came up several times even though it was too technical and concrete to be directly discussed, and we probably have to give it some serious thought. Part of the code for our forges isn't really forge-specific. We have code dealing with configuration, code dealing with input sanitization, code generating HTML output, and so on. Much of that is for generic low-level plumbing required by lots of web applications, with the consequence that generic implementations are often available in libraries or collections of libraries. Or "frameworks", as such collections of libraries are known. Now, that term is frightening because the frameworks are mostly promoted in terms of how easy it is to develop applications on top of them, and we all have old and complex code that we'd need to migrate/refactor, and nobody wants (or has the resources) to port all of a forge to a framework. However, it seems that the reality is less bleak. Several improvements have been implemented in forges (other than FusionForge) using only parts of a framework, which would seem to indicate the migration could be gradual and partial. New features could be using the framework, existing ones could be ported as time permits, but apparently it's not an all-or-nothing work. At least, it seems the Zend framework is, for instance, modular enough that we could use only bits of it at a time. We'll need to investigate deeper, but it sounds like a promising lead.

References

Pointers to presented documents (please add yours) :

Retrieved from "http://wiki.planetforge.org/index.php/Forges_Meeting_February_2010_Proceedings"
Personal tools