Student Application Template
Name: Dionysios Fryganas
Background: I am a fourth year student in software engineering at Fontys University in the Netherlands. I started programming five years ago whith bash scripting to simplify my day to day tasks. In my university, I gained experience with C++ and C# as well as a semester in PHP. On my free time I learned Python and extended my PHP skills. I also developed web applications with PHP for individual organisations. During my universities internship I worked for a company that needed to integrade their REST API of a service they where offering into the most popular CMS and webstore platforms that are written in PHP. That's how I learned the importance of testing and how to work with Test Driven Development methodology.
Why am I suitable for the project?: I have work experience in working with large teams, using best development practices as part of my internship. I have been programming using design patterns in a test driven development methodology for the past year and I understand the importance of testing and maintainability of the produced code. My background in system administration allows me to understand concepts fast enough and adopt them in the projects I am working. I have experience with Redmine, Google Code, Github and Launchpad, minimising the research that the project demands. I am using git to version all my projects but I also worked with SVN and bazaar in the past. Furthermore, PHP is a language I learned on my own time, thus a language I like and I love programming with.
Project title Project import/export for Alioth (?FusionForge)
--- 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.
Synopsis: The project will try and tackle the interoperability problem that the different forge systems introduced. All data of a project should be available and extracted, allowing the community to switch between platforms and VCS tools with the least amount of effort.
Benefits to Debian Interoperability among the community projects and the project data.
Deliverables: A ?FusionForge plugin.
Project schedule: I have already started some reasearch on the topic as well as the additional get up to speed tasks (downloaded the source code, read documentation, experiment with external API's). A draft schedule for tasks per week would be the following.
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.
- Period 1 - 4 weeks
- 1. Read documentation, Meet the community, Discuss the requirements.
- 2. Experiment with the API's of the different platforms.
3. Study the VCS plugins for ?FusionForge and define their (data) commonalities.
- 4. Design a Draft UML and discuss it with the community.
- Period 2 - 5 weeks
- 1. Create the plugin's core functionality
- 2. Work on a unified input/output format
- 3. Create the interface for the input method
- 4. Create the interface for the export method
- 5. Get feedback from the community, work on the changes, write tests, created second UML version
- Period 3 - 6 weeks
- 1. Implement the import interface (defined in week3 of period 2)
- 2. Implement the export interface (defined in week4 of period 2)
- 3. Test the code, get feedback, change accordingly
- 4. Implement the VCS migration tools (defined in week 3 of period 1)
- 5. Test, get feedback and add everything to the core of the plugin (created in week1 of period 2)
- 6. Reserved week for risk avoidance, (failures, delays, etc.)
- Period 4 - 1 week
- 1. Wrap everything up and test. Also a reserved week, in a way, for failures.
Exams and other commitments: An exam week at the end of June, exacts dates are not released yet but only two examable subjects.
Why Debian?: I strongly believe that Debian is an organisation that all the open source communities have something to adopt from. This can also be seen by the amount of linux flavors that are based off of Debian. Being part of the community and contributing will be the least I can do for the community that shaped the open source way of collaborating, as well as my ideas as a student of software engineering.
- Are you applying for other projects in SoC?: I am not applying for any other project for GSoc 2014.