[polypaudio-discuss] [ANNOUNCE] Polypaudio 0.9.0

[Jan Schmidt]

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