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 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 it 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.
Watch out:
devel dependencies test deps, we want them
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
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