[gst-devel] splitup proposal

[Zaheer Abbas Merali]

On 30 Jul 2004, at 17:38, Thomas Vander Stichele wrote:

> 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

important goal if we want to release often

> - separate wellmaintained/supported plugins from others

yes!  at least then we can certify that all plugins in a well 
maintained component are good and not broken.

> - 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, ...
>

Sounds great!

> 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.
>

I vote for a) too.  However dont you think this splitup should start 
from 0.9?

Zaheer Abbas