[gst-devel] state of the union

Julien MOUTTE jmoutte at electronic-group.com
Wed Jan 7 12:08:02 CET 2004


> * MAINTAINERSHIP

I completely agree with that responsabilities split. That's real team
work and optimal use of everybody's skills. I doubt a single guy could
maintain efficiently the complete project anymore.

> * CORE VS PLUGINS

For me CORE VS PLUGINS is like GTK VS GNOME, we should definitely be
able to have a clear design, stable API and releases of the core to
write plugins. This way core hackers could hack in their HEAD branch,
release and plugins hackers would port to the new API.

> * WEBSITE

If that's possible to get the whole project on fdo that's my prefered
choice involving companies lead to the current gstreamer.net situation
and that's bad.

> * CVS DECISIONS

> --> add your rules of thumb here.

I think the CORE VS PLUGINS discussion is completely linked with that
one, i would really prefer working on some splitted modules and let core
hackers have fun in their HEAD branch while i m really able to work on
gst-player/totem with a released version of the core and plugins HEAD.
This way i can fix buggy plugins, check my app and release...

> * PLUGINS

This particular point is the one that kicks my motivation away, it is
really annoying to spend 3 hours reading the code of plugins i wrote one
month ago trying to understand what the hell is doing that bloody hack.

As a plugin writer the only things i beg for are:

- a clear explanation on what needs to be changed in plugins and how so
that i can fix them (examples : bufferpool, delayed caps disappeared,
etc...)
- talk to me before committing stuff in plugins i wrote that you don't
understand. This quick thing you wrote that fix your problem locally
will be one hour of work for me to get that done correctly later on and
fix the ten new issues it raised.

So if we are about to put maintainers on plugins i raise my hand to
maintain : ximagesink, xvimagesink, libgstplay and switch.

> * RELEASES

> --> comments go here

Well for us it's not a big effort to split things, but for people trying
to package and distribute it's a real pain in the ass to sort, split,
repack, check, fix and so on... If we really want to be popular i m sure
we have to make that effort and we have to do it ASAP.

> * CODING STYLE

I will do what you guys decide on that.

> * BUILD MAINTENANCE/TESTSUITE

> As a general rule, I would propose that any invasive change needs to
> keep both the build and media test suite going.  If something changes in
> those, we need to figure out first what has broken and fix it before
> moving on to other rewrites.  What do you think ?

Amen !

Thanks for that mail thomas, i m sure that if we manage to sort those
issues correctly year 2004 will be the GStreamer year !

Cheers

-- 
Julien MOUTTE - jmoutte at electronic-group.com
C.T.O.
_________________________________________________________

ELECTRONIC GROUP INTERACTIVE - www.electronic-group.com
World Trade Center, Moll de BARCELONA
Edificio Norte 4 Planta
08039 BARCELONA SPAIN
Tel : +34 93600 23 23 Fax : +34 93600 23 10
_________________________________________________________






More information about the gstreamer-devel mailing list