Not only mod passenger, gitlabhq codebase is uses ruby 1.9. features, so we'll need to package ruby 1.9 also. Also we need to test it against existing gitolite rpm
În data de Tue, 20 Mar 2012 16:32:15 +0200, Kevin Fenzi <email@example.com> a scris:
On Mon, 19 Mar 2012 23:42:59 +0200
Stas Sușcov <firstname.lastname@example.org> wrote:
Well, the big hurdles with this project were mentioned in the previousIf all this stuff sounds interesting, I would be happy to present a
draft on how we could solve FedoraHosted transition to Gitlab, and
ensure its well maintained from now on.
Lately I started to hang on
#fedora-summer-coding|#jbosstesting@freenode, but I'm not sure whom I
should query. I can't see Dan either online.
I also have a Github account: https://github.com/stas
and a resume: http://stas.github.com/resume.html
Thanks in advance for reading this, and I'm looking forward for your
thread. To my mind the first big problem is getting mod_passenger
packaged, and thats something that you may not have much control over.
(It will be done when it's done).
Next would be making sure that there's a group of people who know how
to manage/maintain/operate things so that after the summer is over
there's not a abandonded proof of concept no one can use. ;)
Thanks a lot for openness! :)
Not sure passenger is the problem.
Gitlab uses the awesome Resque, so you will need something like foreman to run the app with it's workers all together (at least this is the easiest way to do that).
I would go with a different stack like unicorn as the webserver and use apache (if you really want to keep it, other-way I would consider nginx) as a reverse proxy.
infrastructure mailing list