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 twocommits 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 Allenproposed 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

identify which gems are missing in Fedora and package them,

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.

In order to find what gems GitLab depends on, I used the Gemfile.lock
and wrote a simple python script1 that computes how many and which gems
Fedora and GitLab have in common. Below are some draft2 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.

Update: I just found out about the gemfile tool that isitfedoraruby.com3
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 defaultimplementation 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!

I say draft, mainly because that is a raw calculation of GitLab's dependencies. One has to take into account the different/old versions that may exist between Fedora and GtiLab. There are also some packages GitLab pulls from git and not rubygems.org. ↩