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 <kevin@scrye.com> a scris: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
reply.
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[1], so you will need something like foreman[2] 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[4] as the webserver and use apache (if you really want to keep it, other-way I would consider nginx) as a reverse proxy.
[1]: https://github.com/gitlabhq/gitlabhq/blob/master/Gemfile#L29
[2]: http://devcenter.heroku.com/articles/procfile#developing_locally_with_foreman
[3]: https://github.com/gitlabhq/gitlabhq/blob/master/Procfile.production
[4]: https://github.com/blog/517-unicorn
_______________________________________________
infrastructure mailing list
infrastructure@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/infrastructure