[gst-devel] splitup proposal

[Benjamin Otte]

random comments:

We have to make sure -plugins and -plugins-extras have an easily
verifiable distinction. I still fear "royalty-free" leads us into
Debian-legal, though it's far better than "unencumbered."

Another criterium I'd like to add is "binaries distributable as LGPL".
(This obviously includes "or more free".)

I don't think we need a distinction between -extras and not -extras in
unstable. Just dump all plugins into it.

Do we release the unstable sutff? I'm not sure how we should handle the
case where there are badly maintained decoders/encoders for rare formats.
If we don't distribute them (even in a bad quality), it reflects badly on
the GStreamer players "all my other players do play westwood cinematics".
I can expect people that need a framerate adjuster in KFramerateAdjuster
to copy that plugin into their code, but I don't think we want Rhythmbox,
Totem, gst-player, etc to include all the badly maintained codecs. Would a
gst-codecs-unstable package make sense?

Would it make sense to change the name from gstreamer-plugins to
gstreamer-multimedia, gstreamer-codecs or similar? I thought about
something that emphasizes that GStreamer is about streaming and the
multimedia capabilities are part of those packages.

Benjamin


On Fri, 30 Jul 2004, 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
> - 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/
>
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by OSTG. Have you noticed the changes on
> Linux.com, ITManagersJournal and NewsForge in the past few weeks? Now,
> one more big change to announce. We are now OSTG- Open Source Technology
> Group. Come see the changes on the new OSTG site. www.ostg.com
> _______________________________________________
> gstreamer-devel mailing list
> gstreamer-devel at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/gstreamer-devel
>