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
On Tue, Mar 20, 2012 at 8:09 PM, Stas Sușcov <stas(a)nerd.ro> wrote:
În data de Tue, 20 Mar 2012 16:32:15 +0200, Kevin Fenzi
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:
>> Thanks in advance for reading this, and I'm looking forward for your
> 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, 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