[gst-devel] state of the union

[in7y118 at public.uni-hamburg.de]

Quoting Thomas Vander Stichele <thomas at apestaart.org>:

> * MAINTAINERSHIP
> 
> a) website
any volunteers?

> b) documentation
What would be that job? documenting? Or making sure it builds? Or making  
developers write docs?

> c) core design
> d) core code
what's the difference?

> e) sets of plugins
> f) build maintenance
> g) packaging
> h) releases
> i) cvs maintenance
> j) cvs decisions, policy, branching
> k) schedule/planning/goals
I think having a maintainer for this won't work. Everybody decides what he 
wants to work on next. I do at least. And I consider this the biggest freedom 
I have.

> l) coding style
You don't need a maintainer there. You just need a coding style once and 
that's it.

> m) tests
> n) platform maintainers 
> 
You're missing common interfaces. (libgstinterfaces and the stuff that's in 
there)

> There are some people who naturally maintain plugins and get annoyed
> when someone else touches them and changes everything.  People work in
> different ways, and we should ensure we can work together well without
> cramping everyone's style.
> 
I consider the main gst-plugins package more or less maintainer-less. 
Especially the big plugins (mad, osssink, vorbisfile, x(v)imagesink, 
videotestsrc, ...) need to always work. I know to always ask before I do 
something, but if something is seriously broken in there, I fix it.
An example was the improper overlay handling of ximagesink, that obviously 
hadn't been tested yet.


> * CORE VS PLUGINS
> 
I never thought people should work with the cvs HEAD core when they develop 
plugins.
It was the unfortunate side effect of 0.7 being so much better than 0.6 that 
everybody wanted to use it while it wasn't really finished.
I think in the 0.8 case the plugin/app people will stay with 0.8 until the 
core is API stable for 0.10 and the core people will port some plugins to 0.9 
while the plugin people backport useful stuff to 0.8.

>  People on both sides have said that we should probably decouple a
> little more, allowing people on both sides to do their work without
> getting in each other's way.  The side benefit would be that we get to
> stabilize the interface between the two more.  What do you think ?
> Should we make a clearer distinction between the two, decouple release
> schedules finally, and shuffle our resources a bit around that split ?
> 
I dunno how possible that is, but I think we should model after glib and gtk 
here. And they still manage to do releases at the same time.
 
> * WEBSITE
> 
> What do you think, is this fine ?
> 
great - or ACK as cool people say now ;)

> * PLUGINS
> 
> Some people like touching every file of code there is, and some just
> like working on a few and doing those very well.  Both styles make
> sense, but are intrinsically conflicting.  I would propose that, for the
> plugins where there is clear maintainership, that maintainership would
> be acknowledged.  For example, it is clear that Ronald has done a lot of
> work on v4l and ffmpeg, and Julien has done a lot of work on ximagesink
> and xvimagesink.  So it's only natural they get maintainership and final
> say on anything that changes there.
> 
As I said above there are some core plugins that just need to work. For not-so-
important stuff this is fine however.
If anybody cares: You're free to do with "my" code whatever you want. Adding 
stuff is fine, redesigning stuff is fine, whatever gets the job done best in 
your opinion. You don't need to ask me. But don't be surprised when I revert 
changes I don't think are OK.

> Also, this won't work well unless the core developers send out clear
> documentation on how to fix plugins, instead of trying to fix up
> everything by themselves.  (this isn't a statement about how it was
> done, it's just a statement on how I think we should do it in the
> future).  Core developers should probably try to get their stuff right
> and clear enough to explain to plugin developers, if we want to make
> sure that external people will have any hope of understanding.
> 
I expect from everyone hacking on GStreamer right now to understand how the 
code works as good as he must know it. I expect everyone of us that is working 
with caps nego a lot to know how the code works. Every code file is open for 
anyone to read and is the best documentation they'll ever get.
Unfortunately we people are quite lazy in that respect.
The API docs are for quick lookup of function arguments and for people who 
don't need to know the internals of GStreamer too much, like application 
writers. But people writing plugins - especially more tricky ones - are 
required to know the source.
And if there are questions they can ask.

> * RELEASES
> 
> Furthermore, a recent comment by Havoc on a GNOME list saying that
> "gnome obviously cannot host mp3 decoding code at all" made me realize
> that gst-plugins as currently distributed is not what can go in into
> GNOME 2.6 *at all*.  Whether we like it or not, it is not acceptable to
> put ffmpeg in any code form on gnome servers and get it distributed. 
> You can get mad (pun intended) about that in general, but it's a real
> problem that needs to be solved before 0.8
> 
A useful media framework today must at least decode mp3, ogg, mpeg and DivX 
avi pretty much out of the box. I think we all agree on that.
Or in short: I agree with David and Ronald.


Benjamin