projects (was: Re: [gst-devel] multifilesink and proposal to merge it with filesink)

[Benjamin Otte]

On Fri, 23 Jul 2004, Thomas Vander Stichele wrote:

> The discussion on what plugins should be in our gst-plugins tarball
> should be done for all plugins.  Not putting one in because we're all
> fed up with how long it takes to autogen.sh or that we have a bunch of
> ill-maintained plugins is the wrong way to do it.
>
We definitely need a discussion on how we handle our projects in the
future.
And we should have a consensus about it before we start the 0.9 series,
because it seems like a wise idea to do splitups/mergers at the beginning.

Of course I wouldn't be me if I didn't have an opinion about it, so here
it goes:
My idea is to keep project sizes small. Big projects tend to have lots of
parts that are unused, unmaintained or similar and as such lower the
quality of the whole project, because they're a lot buggier. This goes
especially for newly added chunks of code, which tend to be very buggy
because they're new. It's also a lot harder to hack on them because you
have to make the same promises about ABI/API compatibility and such.
And it's easier to define maintainers, release managers and such for each
of these projects seperately.

As a consecuence I have started to put functionality that can be cleanly
seperated into different projects. Examples include the new autoplugging
framework, chunklib, libgstui or madgst. There are a lot of other parts I
see that can be cleanly put into their own projects; libgstplay and
dparams are the easiest examples, they have different maintainers,
different development cycles and so on.

The big question that's left is how we manage the splitup of gst-plugins.
I'd like to get a libgstmultimedia going that includes all the stuff
that's currently in gst-libs - base classes and interfaces for multimedia
plugins. After that I'd seperate the plugins into at least 2 groups,
though I'm not sure it's easy to find 2 groups that fit a majority of
people, so I'm up for discussion/flamage/whatever here. I personally would
tend to seperate between "commonly used" and "not commonly used" where
commonly used would be defined as "users of a apps included by/recommended
for desktops expect those", which would include vorbis, alsa, mad, lame,
converters and such, but not multifilesink, synaesthesia, testsink or
mulawdec.

Feel free to get your ideas and opinions about this out into the wild,
too.

Benjamin

PS: gst-ffmpeg needs a maintainer and a release manager.