[gst-devel] What I want out of a "Status Table"

[Stefan Kost]

Hi hi,

if we assume that the gstreamer-hacker are the target audience, that are 
the items I would like to see in the status page:

1) It would be nice if one finds a way to associate open bugzilla issues 
with the report.
This way one could easily see which plugin has open issues.
I have no idea, if bugzilla has an API that one could use to query 
bug-status ...
Otherwise we can maybe have a BUGS or TODO file part of each plugin, 
which just list bugzilla id's.
Or we need conventions about bugzilla reports to easilly associate 
reports to plugins by report title.

2) See if a plugin is maintained.
This would probably require to check last commit to that plugin and 
grepping the author our of gst-inspect/source.
Maybe it would be easier to have a AUTHORS file with each plugin and 
e.g. having a first line like "*** need maintainer ***" to indicate that 
it has been abandoned.

Stefan

Jeffrey C. Ollie schrieb:

>What kinds of information to gather:
>
>1) Element/plug-in name.
>2) Short, one-line description.
>3) Longer, more meaningful description.
>4) Pads:
>	a) Listing of all pads.
>	b) Capabilities.
>	c) Description.
>5) External library dependencies:
>	a) Name of library.
>	b) Link to "home page", not just where the source tarball can
>	   be downloaded.
>	c) Version numbers that are compatible (where known).
>6) Properties:
>	a) Name.
>	b) Description.
>	c) Read/write or read only?
>	d) Type (float, integer, string, etc.)
>	e) Valid values.
>7) Signals.
>7) Platform availability (all platforms, Mac OS X only, anything but
>Windows, etc.)
>8) CVS module/branch/revision number (or whatever) that indicates the
>version of the plug-in that is being referred to.
>
>What this information would be used for:
>
>1) Learning about the plug-ins that are available so that gstreamer apps
>can be developed.
>
>2) Learning about plug-ins that are not available on the current system
>so that appropriate dependencies can be installed and plug-in can be
>made available.
>
>Ideally, this information would be available both to gstreamer-based
>apps (gst-inspect, totem, etc.) and on a web page.  Also, the
>information should _not_ be limited to the plug-ins that have been
>compiled on (or installed on) a particular system because part of the
>point (and where the current gst-inspect fails) is learning about plug-
>ins that are available in the gstreamer source but have not been
>compiled/installed.
>
>Jeff
>
>  
>