[Openal-devel] SI Releases?

[Chris Robinson]

On Monday 13 August 2007 01:05:26 pm Eddy [the Obsessed] Cullen wrote:
> Version numbering
> =================
>
> Please read the Linux Program Library HOWTO at
> http://tldp.org/HOWTO/Program-Library-HOWTO/
>
> Basically, the micro (patch) version should be strictly incremental, so
> that sysadmins know which the latest version is.

That page isn't terribly clear. I looks like it says that you have the base 
libfoo.X name, and X should be incremented whenever the interface changes. 
The OpenAL API is good about keeping backwards compatibility, so does even 
adding a new function while leaving the others alone, constitute a change?

> CMake and Autoconf
> ==================
>
> Personally, I don't understand what is wrong with vanilla Make; All you
> do with CMake is introduce an additional dependency to do a job that can
> be done perfectly well if you invest the time into learning how to use
> Make properly. The Microsoft version of Make (is it nmake?) is next to
> useless and is SOOOO bad as to not even worth bothering with!

CMake can output makefiles. It can also output KDevelop project files, MSVC 
project files, and others, from the same set of scripts. Make itself is 
pretty poor, which is why it needs something like autotools or cmake to set 
it up. In addition, autotools is a set of programs and relies on a bash-like 
shell on a Unix-like system.. CMake does not. It's a single program which 
doesn't rely on your shell or much of your system. Plus, it produces very 
clean output, and is measureably faster than makefiles from autotools.

> Release Schedule
> ================
>
> Dunno if any progress has been made on this front.
>
> My observations of other successful OSS projects (Linux Kernel, WINE),
> is that there is a Code Czar (or Tsar) who dictates what goes into a
> release and determines the release schedule.
>
> It would seem that Jason is the de-facto Czar at the moment and he would
> be delegating the preparation of releases to Chris.

The main problem is time. The Linux Kernel and Wine, for example, have people 
working on it and contributing every day. And while I could work on OpenAL 
most days, I'm still new to this, and all my changes need to go through Jason 
or someone else. And he doesn't have much time to go through everything. I 
would love to get into a (semi-)monthly release schedule, but it's also not 
something I think we want to force out simply because "time's up", and end up 
with a release that most people can't even build or use. Maybe when things 
are stablized, but there's quite a few big changes on the horizon.

> I had considered looking into it myself, but hadn't got very far with
> it. The approach I would suggest is, based on the spec, write a
> COMPREHENSIVE set of tests to confirm the functionality of the current
> implementation. A real yawn-fest, I know, but it's a do-once job.

There is already are some test programs, in the contrib/ directory of the SVN 
tree. Although they don't seem to all work properly on my system (the 
programs themselves, not the functionality they're testing).

> Step 2 would be to define what you want to fix in the next release and
> publish it!. This will help contributors know where to work... Clearly
> in the long term, 1.1 conformance is a high priority...
>
> While we're on the subject, I personally feel that the structure of the
> standards doc isn't as conducive to "working-to-specification" as it
> could be; I personally feel that more numbered headings makes it easier
> to work-to-specification. This may be just some mental blockage that I
> have (hey man, no-one is perfect, not even me! *grin*).
>
> If looking at a release-schedule, how about targeting 3 months to begin
> with? Something that can always be adjusted...

I had planned to start getting a release together as soon as my new capture 
patches got in. I have plenty of other things ready to work on, but I'm 
simply waiting until a release is made.

However, just the other day while trying to help someone with the SVN version, 
I ran across a couple showstopping problems (the SDL backend crashing when 
probed, compiles failing due to missing _GNU_SOURCE in some configurations, 
etc).. things that are difficult to spot if you're not looking in the right 
place. It would've been a disaster, IMO, if a release was made with those 
bugs.

> Dropping of Support for OpenAL
> ==============================
>
> Sad to hear that people are dropping support of OpenAL. I think this is
> more a PR thing than anything else; I know that Creative provide a full
> 1.1 implementation in their Windows drivers (well, for newer cards at
> least). As far as I am aware, there is no API like OpenAL out there
> (SDL, PortAudio and JACK are all low-level); it is the de-facto standard
> for 3D sound (it's even used on the XBox FFS!).

I believe most people would be satisfied with simple stereo panning and 
distance attenuation, both of which are simple to do in software mixing.

I think the real reason for the drop, at least as far as Linux is concerned, 
is that there hasn't been a new release in over a year, there are many 
outstanding bugs, and even getting the SVN version isn't very straight 
forward.

It's easy for people to assume development died, even though that's not 
technically true. I've been working on what I can though, and I hope that 
when I start getting out somewhat regular releases and letting people know 
that bugs are getting fixed, it can be picked back up.