On Mon, 2006-05-29 at 16:36 +0200, Lennart Poettering wrote: > On Mon, 29.05.06 15:41, Jan Schmidt (thaytan at noraisin.net) wrote: > > > The guidelines for moving plugins between modules are here: > > > > http://webcvs.freedesktop.org/gstreamer/gstreamer/docs/random/moving-plugins?rev=1.5&view=markup > > Mhmm, that looks like a lot of bureaucracy to me. I don't think I want > to go through all those requirements just to get gst-polyp included > into upstream gstreamer. Yeah, the checklist can be a bit onerous for new plugins. I'm volunteering to help though. > Especially the requirement to follow gstreamer indenting guidelines > seems a little bit too unreasonable in my eyes. Actually, that's probably the easiest part. The indent script is run automatically as each file is checked into CVS. Keeping a uniform indenting style is designed to make sure diffs aren't enlarged by random whitespace changes, and makes it easier (at least for me) to scan the code. > The funny thing is that not event the ALSA plugin in GStreamer adheres > to those awkward guidelines: the code from gstalsamixer.c doesn't > generate errors with GST_ELEMENT_ERROR but with > GST_WARNING. polypmixer.c follows the ALSA plugin's lead here, so I > guess the polypaudio plugin has no place in gstreamer upstream. No, we know - there are still parts of the guidelines that don't fully apply to existing elements. We're trying to make them conform one-by-one, and making sure that any new plugins do conform before being included. > It doesn't follow: > - coding style > - 1:1 mapping from class name to source file names > - no integration with gstreamer configure script (how could it?) > - no gtkdoc > - no tests > - no i18n > - GST_ELEMENT_ERROR is not used everywhere (just like the ALSA > plugins, see above) > - no README > - no sponsor or core developer I'll have a look at making a patch for these on Friday. > Stuff I don't understand: > - "use correct value, name, nick for enums" This means that enum properties should have the 'name' and 'nick' properties around the right way when they're registered. We had it the wrong way around in several places for a long time, meaning that you had to use the numeric value, or the 'name' (long description) to set enum properties, when you're supposed to be able to use the nick. eg: To get White Noise from the audiotestsrc element, we used to have to set the 'wave' property to either '5' or 'White Noise' when it's supposed to be the nick 'white-noise'. > - "the manual tests should have a valgrind target" There are 2 types of tests that the test framework in GStreamer caters for: automatic and manual. Automatic tests are run by the buildbots after every commit, but don't work for elements like xvimagesink, alsasink and polypsink that rely on some external process or hardwware. Tests for those are supposed to go in the manual tests under tests/icles, so they can be run manually. The requirement is about making sure that the makefile supports a 'testname.valgrind' rule to run each test under valgrind, and is the sort of thing I always get Thomas to do, since his automake foo is strong. J. -- Jan Schmidt thaytan at noraisin.net I had my head shaved while Kerri-Anne Kennerly was close enough to touch. - Peter Hardy
