Update to Speex

[Faidon Liambotis]

Jean-Marc Valin wrote:
> Faidon Liambotis wrote:
>> Well, Debian had a release with 1.1 and Ubuntu had 4 releases already
>> with 1.1.x, soon (less than a month) to be 5.
>> It might be a mistake on our part, but it happened and we can't change
>> that.
> 
> So, should I rename to .so.2 or .so.5 for Ubuntu? What about Fedora?
> They didn't ship 1.1 at all, so bumping would break their stuff for no
> reason. What about another distro that's already at .so.15 ?
Ubuntu shipped 1.1.x with a SONAME of .so.1 in all of its releases.
They didn't bump the SONAME, so there's no reason why .so.2 won't work 
for them.

Note that the debate here is not whether you should do a SONAME bump 
every time a distribution maintainer asks you to do so because they 
fucked up or whatever.

The problem essentialy is, that you consider only 1.0's ABI as released 
while 1.1 is in production use by hundreds of thousands of users.

>> Packages were built using that version and they're depending on that
>> ABI, so we'll have to change the SONAME and the package name.
> 
> I understand the idea. However, the only features that changed were the
> ones in libspeexdsp, which have already broken for every 1.1 release of
> Speex (and nobody cared, why now?).
Because 1.1 didn't break the ABI wrt 1.0, as far as I know.
It just extended it, which is OK.

1.2beta3 however broke the ABI wrt 1.1.

An application that was compiled with 1.1 and used the DSP functions 
will *break* if we update libspeex.so.1 with a version that doesn't have 
these functions.

>> I'm not sure who needs libspeexdsp right now -- forgive me but the usual
>> maintainers are busy for a while now and I had to step up.
> 
> There's a few packages that use the libspeexdsp stuff as it was included
> in libspeex. Ekiga and Mumble would be examples of that. I always
> thought Ekiga was including a copy of Speex anyway (exactly because of
> the API changes).
AFAIK, Ekiga uses opal and Debian's opal does not embed any library.
It depends instead on libspeex 1.1.

Which I guess is the reason of why we shipped 1.1 in the first place.

>> If noone important is and you expect to break the ABI *that* often, I'd
>> be inclined not to release it _at all_ until you feel like its API and
>> ABI are stable.
> 
> Then you cannot ship Mumble.
That's acceptable since we haven't ever shipped Mumble.
Not shipping Ekiga OTOH is out of the question, as you can imagine.

> I've already frozen the ABI on libspeex. I'm *not* going to freeze the
> APi/ABI on libspeexdsp until I'm happy with it. This is still in
> development.
<snip>
> Actually, 1.1 and 1.2beta are basically the same thing. You need to make
> the distinction between the two parts:
> 1) The codec part is the important one that most people use. The API/ABI
> is the same as it was for 1.0.0 and I will *not* change it.
> 2) The "extra" stuff appeared in 1.1.x and I originally put it in
> libspeex directly. I've just moved it to libspeexdsp, but in any case,
> it's not entirely complete yet and the API/ABI may still change a bit.
You have two users, Ekiga and Mumble, with the first being a major one 
(reported in 37911 Debian installations[1]) that chose to _bundle_ your 
library because you are not making a release.

This sounds far from ideal; you may consider libspeexdsp under 
development but it is in fact used in production *now*, as far as I 
understand it.
IMHO, you should just stabilize it and branch it off and do all of your 
work on a future 1.3 version.

>> What do you propose we should do?
> 
> If you want Mumble to work with stock Speex version, then you'll need
> beta4/rc1 when it's released. When's your deadline for updating the
> Speex version?
Will that version (beta4/rc1) come with an ABI freeze?
I'd hate to do a SONAME bump and then have to do yet another one with rc2.

Besides mumble, how do you feel about the general stability of 1.1.12, 
esp. in comparison to 1.2beta3/4?
I'd like to ship something that *you* consider stable and of production 
quality -- and that's a concern much more important than mumble.

As for our release plan, our release team has published the following:
-----
Early March 2008
   Very soft freeze
     Please start thinking about the release when uploading new major
	upstream versions. Only upload to unstable if you are sure that
	the software will be stable before we release. If you are not
	convinced, use experimental as staging area.
...
Mid of June 2008
   Freeze of the non-essential toolchain and all libraries
-----

Thanks,
Faidon

1: http://popcon.debian.org/main/by_inst