FreeGameDev

One week ago, I went to the FSF hackathon for the Gnu 30th anniversary. There, I tried to compile Gnash (the free software flash player replacement) on my laptop. I ran into a lot of issues with libraries. Fortunately, a lot of people were there to help me including the project maintainer. As I result, I eventually got it to compile, and I was able to get it to run latter and play most flash things. The project maintainer felt that was helpful to test the compile and install process to see if there were any issues he missed or needed to fix.

What I am proposing is we have a virtual hackthon for various free software games that need some work. The games must compile and run on at least one (the developers) computer. Others will try to download and install, either from the version control and/or the latest release of the game and see if they can get it to compile and run and if they run into any issues. I'm thinking we could have some sort of on going schedule and put in 2-3 games per week. (one with lower system requirements such as a laptop from 2005, and one with higher system such requirements such as 3d graphics and possibly one with requirements somewhere in the middle so everyone can participate) The developers/mantainers would sit in irc all day and be free to answer any questions that come up about the compile and install process and try to troubleshoot the issues if anything goes wrong (that it probably will since they most likely only tested it on their own computers/distros)

I'm thinking this could be helpful for the purpose of troubleshooting issues, preparing a game for a new release, preparing a game for packaging, and more importantly involving a wider community of people in free software games development. That is why I suggested only 2-3 games per weekend, because it would be hard to do more than that particularly if issues get to be significant. I'm thinking weekends because typically during the week people get free and different times and live in different time zones. We should probably discuss the details more, and developers would pick the best weekend to make themselves available. It is also helpful to have a bunch of other people trying to compile it and run it at the same time to see if they are running into the same or different issues.

Sadly, I think you are overestimating the size of our community by suggesting "only" 2-3 games per weekend. (Nothing would please me more than you being right and me being wrong on this matter though!)

That said, good idea!

I have something similar at my uni, where we do a monthly thing where we contribute to a free project. Maybe have something like that in here too? Contributions may be anything from code to artwork to documentation to testing to... anything.

As long at it involves a bit more in-depth tinkering than just half a dozen people suddenly busting in, compiling the game and leaving as quickly as they entered, it could be useful to developers. If more time and effort is put into it, such as in the form of a few hours of thorough testing or code/art contributions, then as few as 1-3 people would already be enough to make a difference. In that sense, it wouldn't be hard to make this idea happen in some kind of practical form.

Organizing a larger and/or more coherent event frequently might be pretty hard, though. People have so diverse preferences and hardware that it might be hard to even find two people who could poke the same game together. Also, separating people frequenting here from their own projects and planting them on others for a meaningfully long time might be difficult. In my case, spending one weekend per month on something else would already hurt my own project quite a bit, so I probably won't be of much use.

I like idea, it can be quite challenging to find out why it works on one machine, but not another..
Something we could use here, is virtualbox images with minimal installations of various distributions, so that we could bring up a fresh machine for each compile,
and catch any dependancies that are not already checked by configure scripts or mentioned in documentation.

That said, I doubt many will want to invest the massive amount of work involved in doing something like this..