From Fedora Project Wiki
(→‎GitLab gems: rewrite)
(→‎Fedora gems: finalized)
Line 43: Line 43:
====Fedora gems====
====Fedora gems====


Next step is to find which gems that GitLab is using are already packaged.  
Next step is to find which of the gems above are already packaged for Fedora. I have crafted a little bash [https://github.com/axilleas/fedora-gitlab/blob/master/rubysearch.sh script], which searches the repositories of the current Fedora release (no testing/rawhide enabled) for gems. We come up with 387 total gems of which 93 are GitLab's dependencies. In particular:
 
  Gitlab uses 199 gems.
  Fedora has packaged 387 gems.
  There are 93 common gems.
  There should be packaged 106 gems.


Those 106 gems are not final, as there are also others which are not yet in Fedora, but they are packaged by their upstream. Also, there are many gems pending review in [https://bugzilla.redhat.com/query.cgi?component=Package%20Review&product=Fedora&query_format=advanced&short_desc=rubygem-&short_desc_type=allwordssubstr bugzilla].
Unfortunately, there is a caveat which needs to be addressed and that is version mismatch. More about this in [[#Caveats_and_possible_problems_I_may_encounter]].


====Useful tools====
====Useful tools====

Revision as of 08:07, 2 May 2013

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 have a working GitLab instance. 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 of the gems above are already packaged for Fedora. I have crafted a little bash script, which searches the repositories of the current Fedora release (no testing/rawhide enabled) for gems. We come up with 387 total gems of which 93 are GitLab's dependencies. In particular:

 Gitlab uses 199 gems.
 Fedora has packaged 387 gems.
 There are 93 common gems.
 There should be packaged 106 gems.

Those 106 gems are not final, as there are also others which are not yet in Fedora, but they are packaged by their upstream. Also, there are many gems pending review in bugzilla.

Unfortunately, there is a caveat which needs to be addressed and that is version mismatch. More about this in #Caveats_and_possible_problems_I_may_encounter.

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

Service files

systemd

rc.d

MariaDB support

Caveats and possible problems I may encounter

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

A rough timeline

Longterm commitment

Nice to have

Puppet

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