[gst-devel] upcoming core and base releases

[Andy Wingo]

Hi Thomas,

On Wed, 2007-02-21 at 12:26 +0100, Thomas Vander Stichele wrote:
> We used to have an unwritten policy of not commiting stuff to CVS that
> is not ready yet to go in the next release.  This policy allows us to
> actually do releases when we need to (security fixes, important
> features, ...)
> 
> Destabilizing work, work with new unfixed API, .... should all be done
> on a branch.
> 
> Is there a reason to move away from that policy, or should we stick to
> it ?

I'm not certain that this was ever a strict policy. I'm sure you are
aware of the tradeoffs of branches. They allow a conservative core, but
nobody but the interested developer(s) runs them. Historically their
uses have been two: new unstable series, and shunting off someone's work
to obscurity.

An feature whose interface we might expect to change within two micro
releases would be more appropriate as a patchset in bugzilla. A feature
whose interface might be replaced (with deprecation of the old one) in
10 micro releases would be appropriate for HEAD, because without
attention and testing the eventual improvements would never come.

> can we discuss what these changes are

I am uncertain how pull-mode scheduling in a sink element relates to
state changes and the preroll mechanism. I suspect that a pull-mode sink
should not handle prerolling itself, returning SUCCESS on
READY_TO_PAUSED, having its sink already active in pull mode, but with a
cond/mutex like BaseSink's live mode. Currently, alsasink in pull mode
will not go to PLAYING, because making the ringbuffer thread drive the
pipeline directly bypasses the preroll/sync mechanism (as it should be,
IMO).

I guess the right thing to do would be to disable pull-mode scheduling
in audio sinks now. I can do that, it's just a flag. I think the
basesink pull-mode infrastructure is ok, though, and useful for e.g.
sfsink in -bad.

Cheers,

Andy.
-- 
http://wingolog.org/