On 04/10/2013 11:21 PM, Jeffrey Ollie wrote:
- Of the Ruby gems that _are_ packaged, many of them are the wrong version.
Yeap! Using http://www.isitfedoraruby.com/stats/gemfile_toolI was able to see this.Some dependencies of Gitlab are also frozen to some previous version. See https://gemnasium.com/gitlabhq/gitlabhq
- 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 trueand could be cumbersome to package.
- 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
- 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.
- 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 :)