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_toolI 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 trueand 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
:)