Re: Re: Regarding gitlab
Hello team! Hope my reply will reach the correct thread...
My name is Axilleas Pipinellis, a student from Greece currently involved
in a GSoC project and that is to package GitLab for Fedora[0].
I just found out you are making efforts to accomplish the same thing for
Debian, so I would like to share what I have done so far and if possible
to coordinate our efforts for a better upstream support.
I will try to split it into sections.
== Forked gems
The only big stopper for now is the forked gems, as you already know.
From what I got by your discussion is that you are going to patch the
upstream gems with GitLab's forks. May I ask in what stage this process
is by now?
In Fedora there are some guidelines that state that "packaging forks is
fine as long as they are parallel installable and don't interfere with
each other." which unfortunately isn't the case with GitLab. So either I
will ask for a
See a discussion about it in Fedora infra ML [1].
I also compiled a list of the forked gems and their differences of
upstream [2], it may be of help.
== What version of GitLab do you plan to support
Given that a new one comes out every month and some gems may be added or
updated, there should be an ongoing process of packaging if we want to
have the latest version.
Also, how do you plan to package GitLab itself? I mean how are you going
to follow the FHS?
== Version mismatch
This is also one big problem we have to encounter. There is the upstream
version, the one GitLab uses (may be pinned to an older one), and then
there is the distro's version.
In Fedora we try to package the latest version but in the case of GitLab
that is not always the case [3].
Here [4] is a table of all these versions specifically compared to
Fedora (I compare with the devel repo named Rawhide). I compiled this
list by using this hacky method [5]. If that would be easy for you to
traverse the gems, I saved them in json format, see my github repo [6].
What are your plans on this matter?
== Testing GitLab with packaged gems
How are you going to do this? I was thinking to remove one gem from the
Gemfile at a time and use the one I packaged instead and test if that
works. But that would require a lot of testing and time to do.
Or what my mentor suggested, maybe use "bundle install --local" which
prefers local gems instead of remote and also check on bundler_ext[7],
which tries to workaround some bundler issues with rpm/deb packages.
== Getting close to GitLab devs
There is a campfire chat channel for GitLab contributors, maybe one of
you could request an invite as a representative. That way we could talk
on the fly and you could ask questions to devs directly.
That's all that comes to mind right now, if I think of something else
I'll let you know :) Hope we can work on this somehow.
------------------------------
[0]
https://fedoraproject.org/wiki/GSOC_2013/Student_Application_Axilleas/Gitlab%28463%29
[1]
https://lists.fedoraproject.org/pipermail/infrastructure/2013-July/013203.html
[2]
https://github.com/axilleas/gsoc/blob/master/packaging.md#gem-packaging-on-gitlab-forks
[3] https://gemnasium.com/gitlabhq/gitlabhq
[4] https://fedoraproject.org/wiki/User:Axilleas/GitLab#Packages
[5]
http://axilleas.me/en/blog/2013/gsoc-weekly-update-1/#list-of-gems-to-package
[6] https://github.com/axilleas/gsoc
[7] https://github.com/bundlerext/bundler_ext
--
FAS : axilleas
GPG : 0xABF99BE5
Blog: http://axilleas.me
Reply to: