[gst-devel] clocking

[Christian Schaller]

On Thu, 2004-02-05 at 19:05 +0100, in7y118 at public.uni-hamburg.de wrote:
> The reason why everything clocking related is in such a bad state is because 
> clocking was extremely broken even in 0.6 and I only fund out at the beginning 
> of January when we were supposed to be API stable.
> Getting this fixed correctly with thinking about how it should be done, 
> implementing and testing it would have taken until February and would have 
> involved API changes.

The point of an API freeze is to get the system stable and make things
work instead of adding new features. It should never be used as an
excuse to leave things broken. And with broken I mean real broken, not
'not perfect' broken.

> So from my point of view clocking is as broken as threading: It works most of 
> the time, but don't dig too deep or it will blow up.

Well the basic broken vs not-broken test here is this: Is it possible
for us to have a perfectly working video player? If the question is yes,
then it is something we can live with for 0.8.x. If the question is no,
then we have a bug that needs to be fixed API freeze or not.

The point of api freezes is not to have something to hit over each
others head, but as a tool to help us make sure that we have a working
system ready in time. This includes a system which has a stable enough
API for our application developers to test with before 0.8.x is
declared. 

So the question is, does the current clocking system pass the basic test
I outlined and if not, how/who will try and tackle it.

Christian