On Thu, 8 Mar 2012 14:46:01 -0500
Dan Allen <dan.j.allen(a)gmail.com> wrote:
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 fedorahosted.org
. 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
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
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 $projectname.fedorahosted.org hostnames for Everything. Then
we can have dns bounce people around to whichever host has their code.
Mainly so we don't need a 'fedorahosted.org/projectname' 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 fedorahosted.org
up as-is and just put
new, git-based projects on the gitlabhq servers and migrate things off