On 04/10/2013 11:21 PM, Jeffrey Ollie wrote:

2) Of the Ruby gems that _are_ packaged, many of them are the wrong version.
Yeap! Using http://www.isitfedoraruby.com/stats/gemfile_tool I was able
to see this. Some dependencies of Gitlab are also frozen to some previous version.
See https://gemnasium.com/gitlabhq/gitlabhq
3) For some of the Ruby gems that GitLab requires, it requires git
snaphots of non-released versions,or versions that have been
forked/patched by GitLab developers.
That is also true and could be cumbersome to package.
4) I'm not sure GitLab releases tarballs, as the install instructions
refer to checking out git branches, even for the stable release
branch.
Luckily, they use tags
https://github.com/gitlabhq/gitlabhq/tags
5) There's no ability to fork a project from the web interface, and
thus have GitLab track merge requests.  There's some upstream work on
implementing this feature but all of the patches that I saw had been
rejected.  Personally, I feel that this is a big show-stopper as it's
one of GitHub's best features and why it has become so popular.
I want to believe that at some point this will be implemented. Gitlab has gained
a lot of supporters the past year and the project is constantly evolving. Same goes
with the repositories' public access that Kevin brought up in his previous mail.
6) I have pretty decent systemd service files for GitLab, let me know
if you want 'em.
That would be great, thanks! Email me or contact me via github :)