On Wed, Apr 10, 2013 at 2:15 PM, Kevin Fenzi <kevin@xxxxxxxxx> wrote: > On Wed, 10 Apr 2013 21:02:24 +0300 > Axilleas Pipinellis <axilleas@xxxxxxxxxxxx> wrote: > >> Cross posting from Ruby-sig: >> >> Hello everyone! It's been over a month since I last wrote to this list >> regarding the GitLab project. >> I managed to make a blog post of the story so far[0], any feedback >> welcomed :) I recently deployed GitLab for $DAYJOB and what I found was (at least the big items): 1) As your blog post mentions there are a lot of Ruby gems that GitLab needs that are not packaged. 2) Of the Ruby gems that _are_ packaged, many of them are the wrong version. 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. 4) I'm not sure GitLab releases tarballs, as the install instructions refer to checking out git branches, even for the stable release branch. 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. 6) I have pretty decent systemd service files for GitLab, let me know if you want 'em. > 2. we looked more at gitlab recently, and one difficult thing is that > it's not so geared for public access. For my setup, it wasn't as issue as we don't want public access to our instance. -- Jeff Ollie _______________________________________________ infrastructure mailing list infrastructure@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/infrastructure
