GSoC idea to setup Gitlab for Fedora Hosted, looking for mentors

seth vidal skvidal at
Thu Mar 8 20:03:30 UTC 2012

On Thu, 8 Mar 2012 14:46:01 -0500
Dan Allen <dan.j.allen at> wrote:

> Hello everyone,
> Since this is my first post, I'll start with a quick introduction.
> I'm a core developer in the JBoss Community. I've been working for
> Red Hat for 3+ years. Down to business.
> I proposed an idea on the Fedora GSoC 2012 page to research using
> Gitlab as a front end to Gitlab is like an open
> source clone of Github, supporting code workflow features such as
> pull requests, code review and repository status updates.
> I'm looking for someone who would be interested in mentoring this
> project, as well clarifying to goals if necessary.
> My hope is that this will help curb the rush of projects moving to
> github, which is great, but also proprietary infrastructure :(
> I was thinking about two possible approaches here:
> 1. Work in a staging server, putting the Fedora packaging stuff aside
> for the moment and just get an idea of how it will interface with
> and the FAS accounts...basically, a proof of concept.
> Obviously, the users who have access to the deployed system would
> need to be limited to avoid the proof of concept becoming prematurely
> adopted.

I think I can give you a test instance to build gitlabhq on if you
would like. It would be a dirty/fast setup - so you wouldn't want to
rely on it from a backup/persistence standpoint - but it lets you take
notes on what the hangups for deployment or in use.

> 2. The other avenue is to just assume we want this and move along the
> lines of packaging Gitlab and its dependencies so that it can be
> easily installed on a Fedora machine. Then, infrastructure could take
> it from there and handle setting it up after that project is done.

I'd like to see a test instance before we pkg it, honestly. If only to
see if it is even worth the packaging work.

Some changes we've talked about in the past that would be necessary if
we were to want to use gitlabhq:

1. move to $ hostnames for Everything. Then
we can have dns bounce people around to whichever host has their code.
Mainly so we don't need a '' server which
just does redirects.

2. We'll need to get people off of the model of using for their git repos and over to,

The  advantage we get out of the above is we don't need a load balancer
to automatically support multiple machines on the backend for multiple
projects. It also means we can know who we are impacting in the event
of an outage, immediately, based on which machine is offline.

the problem is it means, potentially, running a backward compat
redirector somewhere (ugh) or having a flag day to get people to fix
their repos and webpages (also ugh).

We could, potentially, leave up as-is and just put
new, git-based projects on the gitlabhq servers and migrate things off
that way.



More information about the infrastructure mailing list