[gst-devel] clocking

[Benjamin Otte]

On Thu, 5 Feb 2004, Christian Schaller wrote:

> 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.
>
Yes, it does exactly that. But don't expect much more.

Benjamin