0.3

[Lucifer]

You should be able to get reasonable sound by setting SOUND_BUFFER_SIZE up to 25. That's a 300 millisecond buffer for 44.1khz sound. You're supposed to fool with it now until you get good sound, if it's possible. I'd try throwing it all the way up to 25 and then lowering it to something like 0.1 or 0.01 and see how it does.

If this doesn't fix it for you, we should note your system in the release notes and ask for more input from people who run the development series. I'm doing serious work in there right now that may or may not resolve it for you, but I've completely rethought how it should look anyway. Also, I hope to re-enable the old sound code (for the most part), so you'll be able to compare it. But this is more long-term work, won't be done if we're going to do 0.3 anytime soon.

It could be a problem with sdl_mixer on your platform, or more likely how we're using it currently. Can you try Crimson Fields, if you have't already? I stole most of the initial batch of code I used from there...

[Lucifer]

Sooo, what's left? Besides wrtlprnft breaking the cockpit map today...

[Z-Man]

NEWS. You guys haven't updated it

Do we need an RPM build? All the alphas were fine without one. If the answer is yes, I'll have to have a look at it.

[Lucifer]

source, windows and mac binaries, and autopackage, and I'm happy. Is there any reason we should do more than that?

[Z-Man]

Weeel, it will be a release, and so far, we always had RPMs with them. They were rather popular; autopackage is catching up, but we want this version tested, right? So having RPMs should be a good thing.
Besides, I'm almost done with the adaptions. Wasn't much.

[wrtlprnft]

Sooo, what's left? Besides wrtlprnft breaking the cockpit map today...

Gah, yet another stupid mistake, fixed.

[Lucifer]

Hmm, you wanna do an rpm knock yourself out. I think what I said can be the absolute minimum for a development release, but I don't know that we need to go apeshit on packages unless you really want to, or you need to test a package format or something like that.

[Z-Man]

Well, it's easier to maintain the rpm build continuously than it is to only start caring about it at stable release time. It's just proactive laziness at work again The RPM build works now in the sense that it goes through without errors. We'll let the users see whether it installs and runs

[Tank Program]

Side note with the sound stuff: You need to be aware of the differences between cards that support hardware mixing and don't. Cards that support it, ie, Audigy cards, will let more than one app (ie xmms and tron) access sounds directly simultaneously. A cheaper or older card (ie AC'97) will only let one app access it directly, and hence things like arts, esd, and more.

[Lucifer]

Ok, last call. We either need to put out 0.3 or branch to stabilize it.

I can give a shot at the autopackage build, but I'm not setup for anything but source release right now, I'd have to install the autopackage SDK at that. I don't even know if there's rpm available for Kubuntu, heh.

[Z-Man]

I can do the autopackage and RPM builds if I get the source tarball, and I can do the source tarball if I get a tag or a "do it from how the trunk is right now" command.

[Lucifer]

How about r4846?

I'll tag it in a few minutes, we should go dig up our QA team and get them to run it a bit, eh? Where's our QA team at right now?

[Lucifer]

Ok, tagged. Umm, mind taking a minute to see that I did it right?

[Z-Man]

It looks right. Expect the builds to be uploaded to aabeta in about 12 hours.

The plan is to release 0.3.0 directly without alpha? Because that's what happens when I build from a tag named 0.3.0.

Edit: err, no, the tag is not completely correct, you should have copied over the build modules as well. That's important for reconstructing later which winlibs version was used and such. I'll fix that.

I may not be able to do the Windows builds. I don't have the required Code::Blocks version just yet. It should work, but I may have to delegate it to Joda if it doesn't.

[Lucifer]

Well, my plan was to build 0.3.0 with the tag and send it to SQUAT and give them some time with it. If they don't find any nasty showstopper type stuff (crashes under regular use), then we release like that. If they do, then I don't know. We can delete the tag and start with the same revision in the branch directory, and remake the tag when we're ready, or we can just commit to the tag.

Maybe I should've copied it to branches instead?

Otherwise, no, no alpha the way we do alphas otherwise. I thought the SQUAT was supposed to do that for us. Was I wrong?