> > You may have looked at the wrong place. It is definitely true that my > Crossfire-0.97.0 consumed about 40% CPU power when loading the map of David. What "map of david"? What map is this? > - Bugs difficult to correct will not be resolved because it is too > time-consuming; Ever heard of milestones? We defer the major fixes we foresee to get something servicable and stable out soon. We'll leave the hard project which involves ripping out the innards and restructuring for 2.0. The hope is that with a reasonable 1.0 out, we'll generate more developer and player interest in contribution to crossfire. This was a consensus decision by the developers: the current code freeze--which Mark has the unpleasant task of enforcing--is directly serving that purpose. We do not have enough people NOR time to fix everything, and getting a 1.0 out is, we hope, a way to get MORE people AND programmer/designer/artist time to help with this game. We should NOT wait until 1.0 is completely perfect before releasing it. > - Getting a '1.0' version number is more important than having a 'clean' > program (note that in the TODO file, 1.0 is 'First true public release - > fully stable, and very well balanced.' I see 'fully stable', not 'to be > released as quick as reasonably possible'). Have you missed all the bugfixes that have gone in recently? This crash fixed, that crash fixed, another crash fixed, this weird thing removed, that bug killed.... and on and on and on. Where have you BEEN? Mean time to server crash has tripled in the last several weeks, mostly due to Mark's efforts, with some help from the rest of us. TREMENDOUS progress has been made. > - Getting a '1.0' version number is more important than wishes of players and > mapmakers (If Mr. Delbecq encountered the bug, it is certainly a problem for > him and potentially for others, even if 'this is generally not a problem for > public servers'). Yeah, we all wish for a totally fast and totally bugfree server. Who, however, is going to do the work? If Mark strangles the developers from doing creative new stuff (the main attraction of working with crossfire) for too long, they'll leave. *that* is an excellent reason to push 1.0 out and lift the code freeze as soon as possible, while also serving the need for stability and game balance. It'd be REALLY nice if we could also eliminate the performance problem, but Mark (and I, and others) think the problem is due to poor algorithms in certain sections of the code, which would be a MAJOR rip-and-rework job, best undertaken past the current milestone goal, which is release of a version called 1.0, which has stability and balance as its primary goals. We'd all be thrilled if you could demonstrate otherwise and provide a simple patch, one we could be sure wouldn't hurt the PRIMARY goal of stability for the 1.0 release. > I think the only feature needed by Crossfire before 1.0 release is a complete > > rethinking on how the code is managed, how players/mapmakers can make their > wishes known, how the work must be distributed between contributors, how bugs What's wrong with people sending email to crossfire devel, discussing things there, which is how we've done it for a very long time? Or getting on the IRC channel and chatting with the developers and players who happen to be around? And as to distributing work, everyone works on what they want to work on, and have time for, same as ANY open source project. And as to the 'command and control' structure for crossfire development, there aren't that many of us. Mark's doing the bulk of the work, *and* has shouldered the job of lead maintainer, a job NO ONE else wanted. It's only fair that he have a good bit of control over development. And your charge of this being a 'closed' open source project are completely off-base. Most people who've really wanted access have GOT it: I know of no one who hasn't. In fact, we've pushed access onto people who were reluctant to have it so that they'd quit bugging us to incorporate their patches! PeterM