Maintenance of celt

[Ron]

Heya Craig,

On Mon, Jun 22, 2009 at 06:31:22PM +1000, Craig Southeren wrote:
> From the point of view of Opal, CELT is one of a variety of codecs that  
> have dependencies on other libraries, just like Speex or GSM.

This one isn't quite like Speex and GSM yet though, as we have a stable
bitstream format and API for those now.  By all indications it seems to
be performing very well, but it's too early to say there are things that
won't be done to make it perform even better.

> As Opal developers, we don't keep track of those libraries very closely  
> - we simply don't have the time - so we rely on users and the packagers  
> to alert us to any issues that come up.

To be clear, I don't want to discourage people from experimenting with
it, that is why we made some initial packages available.  We just need
to make sure everyone who chooses to experiment knows that is what they
are doing.

For instance you could stream realtime audio with it just fine, so long
as you realise two apps using different versions may not be able to
communicate with each other, and trying to store the data in that format
runs the risk of not being able to read it again later etc.

> The CELT plugin in Opal was contributed by Stefan Knoblich and checked  
> in by me. While I am not a user of CELT myself, it would be nice to know  
> that this capability is still available.

For that to be ensured, someone probably will have to take responsibility
for actively maintaining it.  The API probably won't change radically
very often, but you will probably need to update or rebuild your code for
each new celt release -- or at least be prepared to.

Upstream was very responsive to getting us a stable speex in time for
Lenny.  I'm sort of expecting we'll do something similar as Squeeze
prepares to freeze, but I can't guarantee he'll be totally happy to
lock down a 1.0 by then.  Until we do that though the packages will
likely be a bit wild-west.  There'll be no transition packages because
we won't actually _want_ people to keep using older versions at this
stage.

> My preferred situation would be to see new CELT packages arrive  
> periodically so we can make sure that Opal is tracking the CELT  
> development process.

Well, it's the definition of 'periodically' that's interesting here :)

> This allows us to make lots of small changes (which  
> is easier to schedule) instead of one big change when CELT is released.  

And the definition of 'small' and 'lots' too :)

> More releases now also allows users to try CELT right now, which is good  
> for Opal and good for CELT.

Actually, typically users don't come en masse until you _stop_ changing
things at a frantic pace.  But there's a balance, we just need to find
it, and recognise that's a moving target too.

> As Eric Raymond said, "Release early, release often"

Eric has said a lot of stupid things over the years.  There is more to
software engineering and release management than snappy epithets :)

> But I'll fit in with whatever the CELT packagers decide :)

It looks like JM bumped the release version to 0.6.0 yesterday (and
bumped the bitstream version also, so clearly it _is_ still changing),
but I don't see a tag on that yet.  That seems like a good point to
sync to now.  I'll let him finish his testing and put the tag down
then make that available for people.

> I don't have a problem with the CELT bitstream or API changing between  
> now and the final release, and I'm certainly not asking for a  
> compatibility "guarantee".  Packagers know (now) that the package is not  
> finalised, and should make sure it only gets released where it should.
>
> In the end, the users can decide what they want to use, or not.

Yes, this is something that the 'distro people' need to care about.
As upstream opal, you guys should basically be tracking celt from
the upstream git repo if you want lots of small changes every day.

Mostly what you need to keep an eye on from our point of view is to
decide what your best release candidate will be at the time our freeze
deadline comes due.  We can cut a few corners for packages only in
unstable, but come release time we will need a working plan for upgrades
from the previously released version, and to the next release version.

If we don't do that, or get it wrong, you won't have to worry about
the users for very much longer ... : )

> As for responding to queries on this dependency, I've not seen any. If  
> anyone has any Opal questions, feel free to email me directly.

I hadn't heard anything about Opal using this before Steve's mail.
There was a query about updating it for jackd from a user, but the
maintainers of that didn't respond to my queries to them.
I know mumble wants to start using this soon, but upstream for that
is already in close contact with both JM and myself, so the timing
has been based on that before now.

Plan on having 0.6.0 packages soon.  What happens after that, we'll
have to see, but stay in touch if there are things you think I should
know to not screw you over unexpectedly.

I can only act wilfully in the interests of people whose interests
I actually know -- and I likewise don't have the time or existing
need to track opal closely, so someone will have to honk if things
related to that need my attention.

Cheers,
Ron