On Wed, Apr 10, 2013 at 2:15 PM, Kevin Fenzi <kevin(a)scrye.com> wrote:
On Wed, 10 Apr 2013 21:02:24 +0300
Axilleas Pipinellis <axilleas(a)archlinux.gr> 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, 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
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
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.