În data de Tue, 20 Mar 2012 16:32:15 +0200, Kevin Fenzi <kevin(a)scrye.com>
a scris:
On Mon, 19 Mar 2012 23:42:59 +0200
Stas Sușcov <stas(a)nerd.ro> wrote:
> If 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.
Well, the big hurdles with this project were mentioned in the previous
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_for...
[3]:
https://github.com/gitlabhq/gitlabhq/blob/master/Procfile.production
[4]:
https://github.com/blog/517-unicorn