[gst-devel] splitup proposal

[Thomas Vander Stichele]

OK, here's my proposal for solving the issue, and I'll keep it simple.

There are two things I think we need to decide.
First is "what criteria do we use for splitting up"
Second is "how do we do the split on a technical level (code/cvs layout)

First issue, the criteria.

Here are the issues I want to solve with the splitup:
- make releasing each component easier on the release manager
- separate wellmaintained/supported plugins from others
- make sure our distributors ship pristine source
- promote royalty-free formats
- reduce configure/build time
- don't have too many tarballs

I care about each of these issues.  My ideal way of doing it would then
be:

- 4 components; gst-plugins, -extra, -unstable, -unstable-extra
- gst-plugins would contain
  - maintained base libraries and infrastructure
  - maintained gst plugins without deps and without possibly infringing
code
  - maintained gst plugins with deps, but for royalty-free formats
- gst-plugins-extra would depend on gst-plugins and contain
  - maintained gst plugins with/without deps, but with possibly
questionable code
- unstable variants of these two would contain all the plugins that are
badly maintained, have been broken by API changes in core and not
corrected, ...

So, to give you an idea:
gst-plugins would contain x sinks, osssink, alsasink, esdsink, volume,
ffmpegcolorspace, ogg, vorbis, theora, matroska, audioscale,
audioconvert, tcp, ...
gst-plugins-extra would contain mad, mpeg2dec, mpeg plugins, swfdec, ...
gst-plugins-unstable would be afsink/src, monoscope, ...
gst-plugins-unstable-extra would be xvid, xine, ...

The important thing to realize here is that
a) we leverage the advantage GStreamer has over other frameworks - our
plugin-based architecture which makes it possible to easily and legally
distribute parts of it.  This advantage is negated if we don't actually
expose it in our releases.
b) gst-plugins-extra is not a second class citizen - it's just as
important and wellmaintained as gst-plugins.
c) we can tell people that the first two tarballs are the level of
quality we expect from contributed plugins.
d) we still make it easy for people to use formats they already have,
but we intrinsically promote the use of decent open formats.


Second issue, the technical way of doing this.

I think we have two choices.
a) we make four cvs modules, each with their own gettext domain (which
would only be needed for plugins and plugins-extra), own configure,
autogen, ... they are managed mostly independently.
For people who prefer to pretend to work in one module, a cvs alias can
be created, say gst-plugins-all, that embeds these four.  Some
additional glue can make sure that everything gets rebuilt nicely.  This
has been done before; see the old cothreads setup, or gst-ffmpeg.

b) we keep the current cvs module and add a layer on top of this that
can generate four different dirs, autogenerating the build setup to be
able to run make dist on each of them.

Of these two, b) is the most work and the hardest to maintain from my
POV.  So I'd prefer a.

Start shooting :)



Dave/Dina : future TV today ! - http://www.davedina.org/
<-*- thomas (dot) apestaart (dot) org -*->
Anything for a lover 
anything for a friend
I only wanna see you happy 
<-*- thomas (at) apestaart (dot) org -*->
URGent, best radio on the net - 24/7 ! - http://urgent.fm/