GSOC 2013/Student Application Axilleas/Gitlab(463)

Short description

GitLab is an open source MIT licenced git repository management application. It is built on Ruby on Rails and is used by many companies as their internal git management repository. The reason it gained so much popularity is that it bares a strong resemblance to github's looks and feels. It is a project with great potential, under heavy development with a release cycle every month. That "release early, release often" strategy makes it possible to apply bug fixes quite regularly and add new features.

This proposal is aiming to package GitLab and all its dependencies for Fedora and EPEL.

What are the benefits

• Supporting more ruby packages would make Fedora the appropriate distribution for ruby development.

• Fedora is one of the biggest open source communities (if not the biggest) so far, with a very strong community base. If GitLab were to be supported officially, it would gain much more reputation and probably set up as the de facto git management system for other organizations that want control over their personal git repositories.

• Seen many installations on CentOS (forum, issue tracker, blogs), there is demand. rpm packages means "One click install" for Fedora, Red Hat, CentOS and other rpm based distributions. Huge profit, as sysadmins will not have to worry about the manual installation process.

• When the packaging is done GitLab could be deployed as an extra git service for fedorahosted.org. I expect many people to switch their git hosting from the bare gitweb to GitLab. It will enhance collaboration, encourage participation and make coding more fun as it will be an interactive process.

Relevant expertise

Hands on experience

• I have been using/testing GitLab since version 2.0.

• I actively participate in the forum talk, I contribute upstream and I am in direct contact with its developers.

• I have deployed it over 20 times, mostly on Debian, so I am familar with the process.

Other related activities

I have spent several hours contributing not only upstream but I also wrote a wiki article for Archlinux as well as an installation script and recently I gave a small talk in greek about GitLab during a hackfest.

How I intend to implement my proposal

Gem hunting

The first step would be to compile a list of the gems GitLab is using and compare it against the ones already packaged in order to find those missing from the repos.

GitLab gems

Using the Gemfile.lock is a good starting point to compile the needed list. In it there are all the gems GitLab depends on. Many of them are duplicate, so using this little python script leaves us with about 200 gems. Of those 200, most are downloaded from rubygems.org, some are pulled from git repositories, whereas some are patched by GitLab.

However, those gems are not final, as the script doesn't take into account (yet) the development packages which we don't necessarily need in order to get GitLab to work. On the other hand, some of them are needed by the test suite, so one must be careful of what to exclude. I will rework on that script and plan to write it in ruby as well.

Fedora gems

Next step is to find which gems that GitLab is using are already packaged.

Useful tools

• gem2rpm
• isfedoraruby
• gymnasium

Packaging for Fedora/EPEL

Gems

gem2rpm usage

GitLab

how to move from git user, use /etc instead of /home/git

Caveats and possible problems I may encounter

• version mismatch
• test_suite.runs.koji? (gitorious)

Nice to have

Team of maintainers

form a team of maintainers for longterm support even after GSoC is over.

Other details

ruby version. supports >= 1.9.3 , 2.0 rails 4, no support EPEL6