Jump to content
XCOMUFO & Xenocide

"The Frozen Death" Is All Arround Us


Recommended Posts

Well, every open source project has to face The Frozen Death threat.

 

Looks like ufo2000 is suffering from this same problem right now. It is very easy to lose momentum. Just a number of consecutive unfortunate events and the development gets slowed down significantly. Everything started from the problems with the server we recently had, later my company had an urgent work to do and I had to work the whole weekend, and finally I moved to a new place recently and did not have internet at home for some time. All the problems have been resolved, but even now it is a Sunday evening and I did not commit any patch for ufo2000 for the whole weekend. What's the matter? Another problem is the communication, much better would be if anybody could take over project management for the time of my absence and provide some kind of backup. Much worse if the team members are discouraged as well and lose motivation.

 

I think that all the communication is preferably done available to public, it is not fun to have several PM messages asking for help with compilation issues and posting the same answers many times. Even worse is when I can't answer these PM messages in a reasonable period of time, I feel these people may become upset, but I can't do anything to help them sometimes.

 

Here is also a link to an article related to the subject which is worth reading:

http://www.joelonsoftware.com/articles/fog0000000339.html

 

So the cure is simple: just do something, no matter how trivial or nonsignificant the improvement will be, do everything to keep interval between commits at least no longer than a week in order not to lose motivation. Release new public versions as often as possible to get users feedback, even if these new versions do not contain any visible improvements. The point is that if anything goes wrong, the problem will be detected earlier. Some users may not like the idea of being used as guinea pigs, but their help and feedback is very important for project progress. It is good to have some kind of automated feedback system, something like we have here: http://ufo2000.xcomufo.com/results.php

Users just playing the game also provide some kind of quality assurance check and we know how stable each build is. So we have no chance of screwing up :) Even if we release a broken build, the problem will be detected and fixed very soon, in the worst case the last commits will have to be reverted. So this is how everything normally works for ufo2000, if this scheme gets broken (server problem is a good example), the development slows down or even freezes for some time.

Link to comment
Share on other sites

Guest Azrael
So the cure is simple: just do something, no matter how trivial or nonsignificant the improvement will be, do everything to keep interval between commits at least no longer than a week in order not to lose motivation. Release new public versions as often as possible to get users feedback, even if these new versions do not contain any visible improvements. The point is that if anything goes wrong, the problem will be detected earlier. Some users may not like the idea of being used as guinea pigs, but their help and feedback is very important for project progress. It is good to have some kind of automated feedback system, something like we have here: http://ufo2000.xcomufo.com/results.php

Users just playing the game also provide some kind of quality assurance check and we know how stable each build is. So we have no chance of screwing up :) Even if we release a broken build, the problem will be detected and fixed very soon, in the worst case the last commits will have to be reverted. So this is how everything normally works for ufo2000, if this scheme gets broken (server problem is a good example), the development slows down or even freezes for some time.

That's an excellent tactic, I'd love to see it used in Xeno.

Link to comment
Share on other sites

Serge, really liked your post on the issue; I have been there several times and in some aspects we have pretty similar issues in both projects.

 

Az, about the continues integration is what will be done Xenocide regading after the Stackless branch can takeover where the main (too complex) version of Xenocide is. That is why I had setted up the winbuild.projectxenocide.com in one of my Employees servers.

 

Greetings

Red Knight

Link to comment
Share on other sites

Guest Azrael
Az, about the continues integration is what will be done Xenocide regading after the Stackless branch can takeover where the main (too complex) version of Xenocide is. That is why I had setted up the winbuild.projectxenocide.com in one of my Employees servers.

 

Greetings

Red Knight

You lost me there.

Link to comment
Share on other sites

Reed employers, instead of employees...

 

Stackless is a source code branch that is going to eventually takeove the main code branch (the one that has already stagnated, because of its overengineering problems and complexity). We are moving toward a more controlled Continued integration model, with instant build (you can grab the build as it is in the SVN.

 

winbuild.projectxenocide.com is the Continues Integration Virtual Server that my employers (Huddle Group) have donated to Xenocide to do the build.

 

BTW Serge, I dont know if you already or plan to have continues integration; but if you need it after we set it up correctly I extend the offer to UFO2000 too.

 

Greetings

Red Knight

Link to comment
Share on other sites

BTW Serge, I dont know if you already or plan to have continues integration; but if you need it after we set it up correctly I extend the offer to UFO2000 too.

Thanks, that's very interesting. I have no experience dealing with autobuild systems yet though, a good chance to learn something new :)

Link to comment
Share on other sites

Please sign in to comment

You will be able to leave a comment after signing in



Sign In Now
×
×
  • Create New...