[gst-devel] Re: gst-python release (resend)

[David I. Lehn]

* Johan Dahlin <johan at gnome.org> [2004-03-16T14:13:39-0500]:
> Me and thomas wants to do a release of gst-python tomorrow or thursday.
> Is there anything you think is missing or broken?
> 
> I've reorganized things a bit, to be a bit easier to maintain (following
> pygtk's practices),
> 
> so now all modules are in gst:
> 
> gst               # Main module
> gst.interfaces    # Interfaces module
> gst.play          # Play module
> 
> It will require gstreamer 0.8.0 or higher and it does not require
> plugins or player (but will pretty useless without)
> 
> Elements,Bins,Threads,Pipelines,Pads etc should be working from an API
> point of view.
> 
> I have some basic support for TagList, Buffer, Data and Event.
> 
> GstStructure, GstCaps needs to be thought about.
> 
> Comments, Suggestions, Objections?
> 

(sending to gstreamer-devel since other people might be interested)

Yeah, gst-python is due a release.  The only reason I hadn't done a new
release earlier was that the gstplay player.py app wasn't working well
at all for me.  Random failure in various places that I'm assuming are
due to threading issues.  This may only be frequently noticeable on SMP
or hyperthreaded boxes...  which is all I test on so I see this 99% of
the time.  All my useful hacking time went into trying to solve evil
bugs like this - and I failed.  It is a serious blocker bug for me but
if no one else even sees this problem then might as well ignore it at
the moment.

I really haven't followed all the recent extensive changes.  Some of the
ones I've looked at I don't agree with but in any case it's good to see
some progress on the code since I've been busy on other things.  And
progress on gst-python is important so no one decides they'd rather use
the guile bindings. (hi wingo!)

One thing I did notice last time I built the code was that gtk is now
always(?) being loaded.  This is quite annoying and we need to
coordinate with pygtk to fix any requirements for this.  There needs to
be thread locking code at the gobject/glib level rather than only at the
gtk level.  Server apps and people that write code on machines without X
(like me) find it troublesome that non-graphical gst-python apps import
gtk, print "no display found", and exit.

What's the plan for versioning?  I personally would like gst-python to
have its own major.minor.micro versioning and tried to do that with the
0.1.0 release.  But I suppose it's going to confuse everyone if we don't
match major.minor with core.  I'm not sure how to reflect interface
changes with just micro left for gst-python.  I know projects like pygtk
do this but I still don't like it.

I've got a few updates to the docs to check in before a release.  Some
news items and developer names need to be filled in too.

-dave