Re: [crossfire] C++/Qt server version
Hello. I've put a first basic draft at http://wiki.metalforge.net/doku.php/dev%3Aserver_design The first step, though, would be to define the exact kind of game we want, obviously :) Feel free to tweak the page and add stuff you think is missing! (note: the dates are informative, can be changed by some days/weeks if needed - but I don't expect those design steps to take years, actually) Nicolas -- http://nicolas.weeger.org [Petit site d'images, de textes, de code, bref de l'aléatoire !] signature.asc Description: This is a digitally signed message part. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
[crossfire] Client Snapshot Builds
Not at all. They are only difficult because they require availability of each platform. Or, to formulate it differently: it is hard to build a Win32/FreeBSD/Solaris/OSX package without a working installation of Win32/FreeBSD/Solaris/OSX. AFAIK, releasing has little to do with breakage. What I tried to explain was that it was not a good idea to make a release when you don't have the guarantee that it works at least good enough for common, daily use. That's also why the ailesse daily builds were never advertised as releases, but as builds - they don't meet the necessary quality checks of a stable release. Their only purpose is to allow non-programmers to test them and provide feedback. That's also why the Gridarta page on the Crossfire website says No release yet, despite daily builds having been available for months. In short: experimental build != release by far. Agreed, it appears the use of the word release and automated in the subject is the primary concern. They need need not be there. The release procedure mentions nothing about cross-platform checks. Perhaps it should, but if a releaser checks all the platforms at the moment, it is undocumented, and I suspect, not done, by looking at the website client page, so sticking on that point might cause all releasing to stop. I have a Sparcstation I could set up, and enough old hardware for a BSD, but will never have a Mac. The more serious breakage is due to incremental development and a failure to release in a timely manner. Frankly, I see this as a lesser issue than the failure to make current development available The current development can easily be made available through a system of daily builds, again in the same fashion as Gridarta or JXClient, with the caveat that shipping packages for something else than Linux/x86(_64) may be made difficult due to lack of a proper testing infrastructure. Further, automated releases were only one possibility mentioned. The other was for periodic release. From what has been said in the past, it seems releases are not done because it is difficult. The script makes it not difficult. Frankly, I don't get what would make releases so difficult, from the strict package creation side of things. The releaser said it was difficult, and since he does the releases, that's what matters. Its in list history. In response, I addressed the issues I understood to be problems. Just as a side note, a reminder from the Wiki front page: Crossfire works on: - Linux - Windows - All *BSD?s - Mac OSX (Server and clients compile, in testing) So, if we advertise the game as supporting those platforms, then I consider it is our duty to ensure that the releases support them. Note again that I'm considering releases here, not builds. I see from the web site that clients of varying versions are there, demonstrating that we have not stuck to ideals in the past, and probably need not be idealistic at this point even if we do try to improve incrementally. Debian, and other packaging formats are also missing, implying some external effort is understood to be required, but then this is probably approaching the point of beating on dead horses. Besides, people should be able care less whether some niche group happens to like a different x86 client while the rest of the world explores the cross-platform nirvana demonstrated by the other client. I don't think I ever mentioned any kind of cross-platform nirvana - JXClient has its own share of issues, some being related to portability. I don't think I denied you the right of enjoying another client, either. My points were that IMHO: (1) Package creation on an available platform was not a problem; (2) Package creation on a not available platform was a problem; (3) C code daily packages were not made public on ailesse due to (2). Given that your scripting solution didn't seem to adress (2), I found important to underline the issues I encountered with the daily package generation process on ailesse. Got to start somewhere... thats how most problems are tackled... You had a solution, not made public, I did not know about... I had to redo effort. Now I have something, but because it is not perfect must we force the next guy to start from square one? Now, you can consider those issues as irrelevant - I've no problem with that. But then, it means that the new scripts will not make my task as a packager any simpler, making me wondering what purpose they'd then be supposed to fullfill. Many projects do not attempt to package for all platforms but rely on interested parties to care for that and report issues. That's not the same thing as being irrelevent in the purest sense of the word. I would like to see cross platform builds, but I don't want to see the project continue as-is if that is the only reason. Some of the distribution packagers believe that packaging is not something a project should attempt as I have
Re: [crossfire] Client Snapshot Builds
Quick notes (I've probably missed some - if I've missed anything important, follow up). The list of supported platform is largely based on user input. I've not had a mac, so that is based on someone providing patches (if necessary) and saying it works. On going testing of those platforms does not happen by me, and maybe not at all. At one point, I think the list was a lot longer, but then we started asking 'just when is the last time someone tried to compile on irix?'. For what its worth, I've moved for redhat linux to solaris (x86/amd64) so cover that base. The official release cycle is slow for a variety of reasons - off the top of my head: - Broken release system - the tools/components are there, but changes have been made (addition/removal of file being most common) such that release/packaging fails. Not hard to fix, but takes time. - For official releases, desire to have stable components (no big check in the day before). But folks also like to have a chance to fix bug and make other changes before the release, which sort of goes against stability (fixing bugs should make things more stable, but not always the case) - Scheduling becomes a problem - between the packaging, uploading, and updating the page on sourceforge, it would be a couple hour process. It may be the case that I have the time right now, but to let everyone have a chance to put in the patches, change, etc it means a couple weeks time, when I may not have time. - The only real part of the official release was the source tar balls. Binaries may come later or not at all (I only did x86_64 rpms - never did anything more) On those notes, things to make releases happen more often: - Folks other than me doing releases. - Use standard release train model (release happens at this time - if change isn't done, need to wait for next train/release). - More frequent releases such that missing a train isn't as big an issue. - Do more frequent in between snapshots - if this uses same logic/scripts as official releases, it means that problems related to missing files get found sooner. A lot of that is easier said than done. I've also said that I'll try to do releases more often, but finding time to do so is often hard. And even on second point of release train model, I suspect that dates would be vague or in a range (something along the lines of 'Release schedule will be January, May and September'). That gives entire month to find the necessary time for a release, and not a specific day. One last note - with various free VM solutions out there, it now does make it easier to releases for multiple OS's or doing 32 bit releases on 64 bit linux (I know of the problem Lauwenmark speaks related to trying to do a 32 bit release on 64 bit linux - solution would be to have a 32 version installed in a VM) Now in terms of the 2.x branch: For the client, given that lots of good stuff has gone into the 2.x branch and nothing really removed that breaks compatibility, I'd be tempted to take what is currently 2.x and make it the main trunk (I'd need to think about it more and see what changes have been done). To prevent confusion, a long time back it was decided that the client would mirror server version - that normally worked pretty good when we were just doing incremental 1.x release, but doesn't work as good for 2.x. The reason for tying the versions together is it made support easier - just tell users to make sure their client was at least same version as server and things would work. But also since that time, the protocol has stabilized a great deal. Now the idea of the 2.x client (and thus server) was that at time of release of 2.0, the client would fully support the 2.0 protocol and nothing more (all code related to deprecated commands would be removed. All setup or other option related to protocol control would also be removed, such that at startup, the two would already be speaking the same language. Some setup commands related more to control/preferences would still be in place). Such a client almost certainly would not run on a 1.x server, and a 1.x client would not work with a 2.x server. But that hasn't happened yet, and the current trunk client certainly does work on the 1.x servers, so maybe it does make sense to take what is in trunk and call it 1.x - it would get more folks using the features that are there. It may just make sense to just work on trunk until such time when it really does become incompatible with 1.x clients. For the server, this is a trickier question - the trunk server clearly is not ready for official release - sure it will run, but work on balance and other areas need to be done. One has to ask what do we get by releasing it more widely - I think we'd certainly get a fair number of bugs or questions related to known issues. I'd be more tempted to do snapshot releases after certain major things are done but
