Update: I just got a confirmation mail that my proposal got accepted! Read here.

So, I decided to write some info regarding my involvement for this year's Google Summer of Code. I have been using/testing GitLab since version 2.0 (almost a year now) and I am thrilled to see how much it has growed since. This year I got a little more involved into this and I made two commits upstream. Nothing fancy, but I hope to contribute more as time passes by.

In the rest of this article I will try to explain what GitLab is, how Fedora is involved into all this and what are the benefits of this involvement. This is the first of many follow-up posts I intend to write, so keep tight!

What is GitLab?

GitLab is an open source MIT licenced git repository management application. It is built on Ruby on Rails and is one of the most popular projects featured on Github. It 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 makes it possible to apply bug fixes quite regularly and test new features. And since a picture is worth a thousand words, here is a demo site where you can test all the latest features.

Fedora's involvement so far

The thought of GitLab being packaged and deployed for Fedora Hosted isn't new. It all started last March when Dan Allen proposed GitLab to be used as a service for Fedora Hosted. If you follow the conversation it summarizes to some key points:

• Projects pages should be ideally hosted as $projectname.fedorahosted.org.
• GitLab and its dependencies should be packaged for Fedora and EPEL 6.
• Puppetize the whole thing up. There are some configs, but they'll sure need some adjustment.
• We need to form a team of maintainers for longterm support even after GSoC is over.

There was even a post in GitLab's list, also by Dan Allen, bringing the project to the attention of the GitLab community. The most interesting thing was that the lead developer of GitLab was more than willing to help. In the end, there was an application but unfortunately that was the last anyone heard about the project.

So, here we are a year after with me applying for the project. To be exact there is another sudent interested in this as well, so that makes it two of us. I have already expressed my interest in RubySIG and in the infrastructure mailing list. I was glad to see that there was a positive response from Dan Allen, as well as some valuable advice from user Ken Dreyer who currently tries to deal with Gitorious.

What are the benefits

There are two major benefits for Fedora.

Get more ruby packages in the repos

Prior to addressing my interest in the mailing lists, I approached Vít Ondruch to get some feedback about this task. He was very helpful and pointed me to what should be done as a first step. That is

1. identify which gems are missing in Fedora and package them,
2. compile a list of gems GitLab is using, including all their dependencies (and possibly bundled dependencies).

For the first task, I used a hackish bash script which first accumulates all rubygems in a file and then removes the duplicate packages and the ones that are documentation.

#!/bin/bash

file_raw='/home/axil/tools/fedora-gitlab/rubygems_fedora_raw'
file_new='/home/axil/tools/fedora-gitlab/rubygems_fedora'

yum search all rubygem | awk '{print $1}' > $file_raw

sed -e 's/rubygem-//g' -e 's/.noarch//g' -e 's/.x86_64//g' \
-e '/i686/d' -e '/==/d' -e '/:/d' -e '/-doc/d' < $file_raw > $file_new

In order to find what gems GitLab depends on, I used the Gemfile.lock and wrote a simple python script¹ that computes how many and which gems Fedora and GitLab have in common. Below are some draft² numbers and a bar chart.

Gitlab uses: 203 gems.

Fedora has packaged: 385 gems.

There are 97 common gems.

There should be packaged: 106 gems.

Fedora will have 27.53 % more ruby packages, that is 482 gems in total.

Not bad, 106 more ruby packages! That is a plus now that Fedora is considered one of Ruby's supported platforms.

Update: I just found out about the gemfile tool that isitfedoraruby.com³ is using. This will come in handy.

A new service for fedorahosted.org

After the packaging is done, the next big thing is the deployment process on Fedora Hosted as a new service. Quoting Dan Allen's thought:

One of the key reasons I've been pushing for GitLab is because I see the potential it has for drastically improving the discoverability of the Fedora code base and encourage participation. I've been involved with a lot of projects on GitHub and I'm amazed by how simple it is to submit changes (to both code and documentation). In fact, it's often easier to send a patch with a description of the change than to create an issue...flipping the normal bug submitting process on its head.

GitHub also works because it enables collaboration over coordination. You don't have to ask for permission on GitHub. You just do it. Then you can easily track when they get pulled in or changes are requested. (the same is true of GitLab).

With GitLab, we can bring that experience to the Fedora community. It's a large enough community (esp in terms of repositories), that I'm positive we'd see that collaboration kindle within the Fedora instance.

So yeah, this is a big deal from this point of view :)

Next steps and things to overcome

There is certainly a lot more to do. For starters, as a Fedora newbie, I have to run through the Ruby guidelines and learn about the philosophy of rpm. Luckily, I am not a linux newbie (I've been using Archlinux for 5 years) and I am adopting rapidly. Then, I need to learn some Ruby. I have already printed why's (poignant) Guide to Ruby which is considered a must read, and believe me it is! (download the pdf from here). Learn Ruby the hard way is also a good starting point. Ι think I'm on the right track.

Now, as far as the packaging process is concerned, here is what more needs to be done:

• MariaDB support. Since MariaDB will be the default implementation of MySQL in Fedora 19, GitLab will need to support it.
• Write systemd service files. I had made an attempt two months ago when I was trying to set up GitLab on Archlinux, but it is far from perfect.
• Packages to be EPEL compatible. A great advantage if GitLab gets packaged for Fedora, is that it would make it as easy as pie to install on a server running Red Hat, Centos, or some other rpm based distro.
• Ruby 2.0 compatibility. I don't think that'll be much of a stopper since GitLab is in the process of supporting it, but I put it here just in case.

That's all for now. If you read through here you should have a good understanding of this project's goal. More posts to come!