[gst-devel] doc progress and tasks

Stefan Kost ensonic at hora-obscura.de
Sun Sep 25 11:13:07 CEST 2005


I am happy to announce that I've finished inlining all gstreamer core
docs from the tmpl/*.sgml files into the respective sources. While doing
that I've splitted some sources. For the future please never again put
several classes into one source-file.
I also updated and add docs on the fly where it was obvious. Still there
is a lot of work ahead.

1.) Review policy:
What about a review policy for major releases? There were really funny
examples in the long-description for gstobject ( -> gtk_bin_add (GTK_BIN
(bin), element); ).  Some docs I came across had a 'last reviewed on
<date>' paragraph.
I don't know what would be the best plan, what I want to say is that I
belive its a good idea to go over the long-description of classes and
check if the stuff in there still applies. I my mind I see a table with
classes on one axis and core-developers on the other axis. whenever a
core-developer reviews the docs and says its okay, the class gets one
point. We then can say two points required for e.g. 0.10.

2.) Filling the holes - part I:
gstminiobject:Long_Description & Short_Description
gsttask:Long_Description & Short_Description

It 14 long desacriptions which are missing still. I am probably being
able to come up with something for some of the, but would appreciate
original author to help here. Having a good long description is quite
useful for the app and plugin developer.
I see this as step #1 to complete the docs and mandatory for 0.10.

3.)  Filling the holes - part II:
Whats the suggestion for filling the holes. Shall we make the buildbots
break on core docs file-by-file? (Fail unless GstBin is complete, the
fail unless GstBus is complete, ...).


More information about the gstreamer-devel mailing list