On the path to creating a Forkolator branch of Gitorious, I’ve been trying to get Gitorious up and running on forkolator.org.  I’ve been documenting this process (and other things I’ve been learning about Ruby on Rails) over on wordpress.com.  I’ve gotten most of Gitorious up and working, and now I’m moving on to try to figure out how to create a system for one-click deployment of Gitorious source trees.

The first step in this process is to try to wrangle a system of web servers into place.  The difficulty is, I need a variety of non-standard stuff all to work together.  I can see how to do A, B, C, and D, but it’s not clear how to get them all working together.  So, let’s see what we need.

1. Virtual domains

Every forkolator deployment needs a url.  And the urls should be something like http://myapp.forkolator.org.  You can set this up easily in Apache with the VirtualDocumentRoot directive, but it doesn’t necessarily play nice with…

2. Suexec

Each forkolator app needs to have relatively tightly controlled permissions.  MyApp should be able to run itself, but shouldn’t be able to to run YourApp, or even necessarily read the contents of YourApp’s files.  At the same time, the processes need to have access to the filesystem, and system libraries.  That means the apps need to be running as different users.  Again, this is easy with Apache with the SuexecUserGroup directive, but it doesn’t work with VirtualDocumentRoot.

3. Environments

In addition, there needs to be access to the development (and testing?) environments, ideally somewhere like http://myapp.dev.forkolator.org.  Unfortunately, Suexec won’t let you pass in the RAILS_ENV variables from your Apache configuration.

Solution

In the end, I think what might be the thing to do is to set up a separate process that starts and stops mongrel server for each app on certain ports with the correct user permissions, and have that process save the ports in a memcached table.  Then a nginx server can handle the incoming requests, look in the table for the proper mongrel server and send the request on its merry way.

This will only work if the nginx configuration can be made smart enough to read a memcached table (or table anywhere) and parse correctly the *.forkolator.org vs. *.dev.forkolator.org urls.  Which I think it can.  I’m just not 100% sure.  We’ll see.  For now I’m going to go work on some schoolwork.  I’ve spent enough time on this for a while.

…

On a side note, it’s sort of sad to me that the Heroku folks have already done a lot of this work, but they are keeping it proprietary instead of sharing it as Free Software.  I think they’ve released a few things as Free Software, but by and large the platform is closed.  It’s especially disappointing since they have benefitted so much from Free Software to build that platform.  I wouldn’t be surprised if Heroku itself is the only proprietary software in their entire stack.  I sense a similar disappointment in Johan with respect to Github.

Well, it doesn’t do much good to sit around wishing people would open source their code, so don’t expect me to talk much about Heroku in the future.  I’d rather focus on making great Free Software anyway.

Some big news: I’ve decided to abandon the PHP codebase I’ve been working on and instead focus my efforts on adapting Gitorious to fit the needs of the Forkolator project.

Gitorious is an awesome project started by  Johan Sørensen which provides a web-based collaborative git repository management system.  It implements a lot of the user stories I’ve been working off of, and it has a small but vibrant community of developers coalescing around it.  And Johan is a fantastic developer and a staunch Free Software advocate.  I’m really excited to join their community.

I also switched the mailing list over to Google Groups, since the forkolator.org server is sort of alpha right now, and the mailing list is mission critical.  Here’s my post about the Gitorious plan.

This is just a quick update about what I’ve been working on… trying to get Forkolator closer to something other people are going to want to work on.First off, I implemented some basic conflict resolution functionality, so that if there are conflicts in a fork you are trying to merge, you can resolve them by hand.

And secondly, I started a basic roadmap. It’s just a few thoughts about what I think we need to get done right away and what we should be focused on in the near future. Comments welcome. Updated: Here’s the actual link! That’d be helpful.

Here’s a screenie:

I’ve been hacking ForkCode on and off over the last month, and after a particularly productive sprint over the last week or so I wanted to put out another release. It’s still in a very scrappy state, but it’s shaping up. New features include:

• Project management features (forking, merging, etc)
• Automatic revision control (through Bazaar integration)
• Better test suite coverage
• Better documentation coverage

I’m making decent progress getting my mockups implemented. I’d like to try and record a demo soon so people can see what can currently be done. I’m also hoping to get this live on a server somewhere soon.

Tarball available on the download page. Obligatory screenshot:

Since there’s been a little confusion about what Forkolator is really supposed to be, I added a page on the subject to the wiki: What is Forkolator?

Some recent press/blogging about Forkolator:

• Sandy Armstrong, a maintainer of the Tomboy note-taking app who I met at BarCamp San Diego, wrote up his response to the project.
• That post showed up on Planet Gnome, prompting Colin Walters, who is a Red Hat developer working on Gnome Online Desktop to add his thoughts.
• At which point the article got picked up by Jake Edge at Linux Weekly News, who wrote a lengthy (and great!) writeup of the project.

And this summer Paul McDonald of the Google Mashup Editor team weighed in. It’s exciting to see people talking!

After a half-day of Wordpress and MediaWiki wrangling, I got a wiki and a blog going here on forkolator.org. Go me! Now we’ve got a place to start putting content!