+#language en

Student Application Template

--- Copy of description ---

Alioth is the reference Debian hosting platform for project code (or "forge"). It supports all majors VCS (Git, Hg, Bzr, SVN...) and offers membership management, bug trackers, discussion lists, download areas, and aims at making team work more efficient using best practices from the Free Software world. Alioth is powered by ?FusionForge.

The forge world currently lacks interoperability: each forge has its own internal data format and few tools are available to migrate data from one forge to another. Moving project code and assets between publication platforms — including your own forge — should be easier, and faster.

Your mission — if you accept it — is to implement an extensive import/export feature for ?FusionForge. You'll probably review the previous experiments with tools (forge-plucker, github-backup, ...), one-way imports and APIs. Defining a common format would clearly be a plus.

--- End of copied description ---

The current situation with ?FusionForge is that it's easy to create a project from scratch and in some cases to add an existing project as a new forge, but is not as easy to extract the information of a forge that is actively in development.

This creates a "confusion" among the community members, since the forges tend to jail the data that are inserted instead of keeping them accessible and easily retriveed outside of the web interface.

The goal of the project is to create a feature as a plugin for the ?FusionForge platform (in extend, Alioth) that will ease the migration from one platform to another. Data created in a forge such as open bugs, source code, trackers, users involved, should be easily extracted and inserted. Ideally the commonalities between forge platforms and VCS tools will have to be defined in order to, not only allow the importation and exportation from one forge platform to another, but also the migration from one VCS specific platform to ?FusionForge. This should be possible within ?FusionForge or between ?FusionForge and a different platform, such as Google Code, ?GitHub, ?SourceForge, Launchpad.

The schedule is seperated into four periods according to Google's schedulle and is subject to changes once discussed with the community members and the mentor.

Period 1: The bonding period will be used for what is intended, to get up to speed, meet the community and also research the available technologies and similar projects. Period 2: The first period will be used for defining the requirements, working on the core implementation and working on the Object Oriented design and the most suitable design patterns to achieve extensibility and maintanability for the future. Period 3: This is the most intense period that comes after the middterms. The implementation of the design defined in the second period will happen during these weeks. Period 4: This is the last week of the schedule, will be used for failure prevention, as well as a week for extensive testing.

In detail, this is how the schedulle will look like.