Update to Speex

[Ron]

Hi Jean-Marc,

Thanks for your input on this, I'd like to try and figure out two things
as quickly as we can:  where have things got screwed up, and what do we
need to do to fix them ...

Once we're all on the same page about that, what to do about it should
be fairly self-evident I hope.  So I have a couple of extra questions:

On Mon, Mar 17, 2008 at 11:10:32AM +1100, 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 ?

So if I've got this straight, the problem here is that we never should
have distributed 1.1 at all in the first place, as it is not perfectly
compatible with either 1.0 or 1.2 ?  (and you never claimed it would be)

In that case, sure, that bit is our mess to fix.  We can do that.

I do see a couple of things that still make this harder than it needs
to be though, which will tend to lead to this sort of mess again in
the future if we don't sort them out...

> > 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?).

It's more likely that nobody noticed.  That doesn't make the problem
less real when someone does bump into it though.  Since we don't all
yet see a solution we agree upon, presumably we aren't all seeing the
problem clearly yet either.  Please correct anything that follows which
is wrong:

 The 1.0 release and libspeex from 1.2beta3 are perfectly compatible.
 Any possible app built with 1.0 can use 1.2 without a rebuild.

 The bits of libspeex that have been changing since 1.1 are now all
 in libspeexdsp

 Neither libspeex nor libspeexdsp depends on the other.  Each could
 be used alone by some application.

 You consider the libspeex API frozen at revision 1.  You reserve
 the right to make further changes to libspeexdsp as required still.

If all that is true, then it sounds like we should ship libspeex.so.1
from 1.2beta4, and split libspeexdsp into at least its own binary .deb
if not its own source package.

The remaining problem in that scenario is that the libspeexdsp soname
currently appears bound to the one used by libspeex.  If we are to
also distribute libspeexdsp (which I would personally like us to),
then the workflow for releases would mean bumping the soname for
libspeexdsp at every public release where its A{P,B}I changes
incompatibly.  That doesn't seem unreasonable, that is precisely
what the soname is for -- but we don't have to get libspeex caught
up in a bump because of it.  Only the people using speexdsp have
to chase the changes, and they made that choice for themselves.

> > We *have* to do the bump. If you don't, we'll have to diverge from you
> > and we don't like that, that's my point.
> 
> Well, by doing that, you'd be diverging from at least Fedora.

What other distros do doesn't really matter, we all do something
stupid from time to time that others would be foolish to follow.

What is important is that you accurately reflect which bits change,
and we accurately pass that information along to the users.  If we
can put a peg in the sand here, and agree on how and when to do
that in the future, it should all be smooth sailing ;)

> I'm not going to break the ABI for libspeex, only for libspeexdsp.

Separating their soname changes is logical then.

> 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).

I've been using the resampler and the preprocessor from 1.2beta2.
Splitting that out is an incompatible change to libspeex from that
release, but we can probably pretend that never happened too if it
will be handled right from here onward.

If Ekiga/Mumble/etc want to be part of a release, they'll just have
to be compatible with libspeexdspN for whatever N is the release
you recommend we ship in distro snapshots.  So long as you increase
N when you make an incompatible release, all will work as it should.

> > 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.

Or we need to package an svn snapshot.  But if you are happy enough with
the current code to at least make a beta4 snapshot, that seems like a
fairly easy better solution all round.

> 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.

If you are happy to bump the speexdsp soname (if needed) when you make
a release you would like us to ship, we can separate these two tracks
of development similarly.

> Can you please take what Debian has in unstable and release as Lenny.
> Then you can just resume work on the next release?

We can't quite do that, there are a few things in that which need to
be tidied, as well as updating it to beta3+ with libspeexdsp split out.

But as soon as I know we're all agreed on the format for 1.2 releases
and how we'll manage the bits we expect might change, I'll get a
package together as a candidate for Lenny based on it.

> 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?

You can find the current schedule here:
http://release.debian.org/emails/release-update-200801

Looks like mid june is the projected hard cutoff for libspeex
releases.  So we need to have all the teething problems and app
transitions over by then.  Parts of the distro are already being
cooled, so we really want to have this transition well on its
way or 'finished' by april if possible.  Apps will still need
time for any issues to shake out with use.


What have I still missed?

Cheers,
Ron