On 04/10/2013 11:21 PM, Jeffrey
Ollie wrote:
Yeap! Using http://www.isitfedoraruby.com/stats/gemfile_tool I was able2) Of the Ruby gems that _are_ packaged, many of them are the wrong version. to see this. Some dependencies of Gitlab are also frozen to some previous version. See https://gemnasium.com/gitlabhq/gitlabhq That is also true and could be cumbersome to package.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. Luckily, they use tags4) I'm not sure GitLab releases tarballs, as the install instructions refer to checking out git branches, even for the stable release branch. https://github.com/gitlabhq/gitlabhq/tags I want to believe that at some point this will be implemented. Gitlab has gained5) 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. 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. That would be great, thanks! Email me or contact me via github :)6) I have pretty decent systemd service files for GitLab, let me know if you want 'em. |
_______________________________________________ infrastructure mailing list infrastructure@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/infrastructure