GitLab packaging progress and discussion about deployment on fedorahosted

Axilleas Pipinellis axilleaspi at
Wed Jul 3 18:57:23 UTC 2013

Dear infra team and others that this mail may concern,

As many of you know (I hope :p), one of this year's GSoC projects, is
to package GitLab and all its dependencies for Fedora and later for
EPEL. There have been at least 3 discussion threads about this since
March [0][1][2][3].

I have been in contact with GitLab's core team and we talked about how
we could all work together to make this happen and how GitLab could be
eventually deployed in fedorahosted as an alternative git service. For
the time being there are 2 major show-stoppers:

1) GitLab uses some forked gems.

These are the forked gems by GitLab which add some extra functionality
or fix some bugs of the original gem:

Upstream      | GitLab
grit	      | gitlab-grit
grack         | gitlab-grack
gollum-lib    | gitlab-gollum-lib
omniauth-ldap | gitlab_omniauth-ldap
pygments.rb   | gitlab-pygments.rb

Vit Ondruch, my mentor, pointed me in these FESCO [4] and FPC [5]
tickets, which pretty much conclude that:

"FESCo is fine with forks as long as they are parallel installable and
don't interfere with each other."


"The FPC does not see a need for additional guidelines relating to
forks at this time, they should be treated like any other package."

I also raised this issue in #fedora-devel today and they told me the
same thing FESCo concluded.

I think GitLab's forks don't abide by FESCo's verdict, as both original
and forked gem are called with the same library, eg. require 'grit', so
there is no distinction between them.

I am cc'ing Sytse Sijbrandij from GitLab's core team to talk about what
changes could be made in order for the forks to get accepted.

2) The feature of public browserability for non logged in users is not
yet implemented.

This long awaited feature is the major show-stopper for getting GitLab
deployed on fedorahosted. Quoting Sytse's proposal:

> Of the two improvements I think that 2) is the most necessary. Without 
> a public project UI Fedora will not switch to GitLab. There is already 
> a public project git clone functionality in GitLab. Opening up more of 
> the project such as issues might load to in-advert exposure of issues. 
> Therefore we want to do it only on a major version upgrade. We started 
> with GitLab 6.0 a week ago and would like to merge this fast so it can 
> be included in the beta released on July 22. If Axilleas works on this 
> then Dmitriy is prepared to coach him, this will be needed since this 
> feature will impact the whole application.
> Our proposal would be to:
> A) Start working on the public UI immediately
> B arrange a online meeting between Fedora and people to talk 
> about packaging
> C) have beta version of GitLab run on a demo server with Fedora project 
> on August 1
> D) aim to have GitLab in production for all Fedora projects on 
> September 1
> Of course this is just a proposal. We have too little knowledge of the 
> Fedora project to make a proper plan.

The initial plan of the GSoC proposal is to package GitLab,
but since I talked about it with Sytse I thought it would be more
productive to bring the discussion here and sort some things out all

Thank you all for your time,


GPG : 0xABF99BE5

More information about the infrastructure mailing list