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

[Darren Blaser]

>>What do people think about having separate pages with different
>>information shown, one for developers (with, say, open bug issues and
>>maintenance status, if possible) and one for users (with, say, links
>>to dependencies and mime types)?
>>    
>>
I think the targeted two table approach may likely end up as the best 
final presentation of the data. In general terms I think users would 
like a plugin based list where developers would better like an element 
plus details based list. IMO generally users won't be interested in any 
details that are of finer grain than a plugin or a dependency as defined 
by an rpm spec file. Developers on the other hand may be interested in 
the fact that a particular plugin may contain multiple elements and that 
a particular element has a specific library based dependency among other 
things.

I'll end with a bit of encouragement.  ;-)   I'm mostly just eager at 
this point to see a prototype status table of sorts with some data in 
it. It should be easy enough to expand/modify/alter to reach our goals 
once there is something specific and concrete to work on... Having a 
prototype may also make it easier to specifically answer the issue 
Benjamin raised earlier about figuring out why the previous tables were 
not maintained (which is still a very good question possibly not 
sufficiently answered).

If we start with the element based list it should be easy enough to look 
at and then say "there's too much redundant info here let's fall back to 
more of a plugin based approach" or "this is great, now lets just 
extract this portion and add in this item and we will have a beautiful 
user table"