[DSOUND] add DirectSoundFullDuplex support

[Molle Bestefich]

> > Why not do this:
> >   Accept the patches into trunk, and do the "code freeze" in a branch.
> > Pros:
> >  - Developers of patches will not get pissed (ahem) for their stuff not getting in.
>
> In the open source world, anyone submitting
> a patch has to count on patiently resubmitting it
> a few times until the maintainer is ready for it.

That's a piece of monkey work right there that everybody would be
freed from, isn't it?

> Wine is no different that gcc or the linux kernel
> in this regard.

Who says that they're doing things efficiently?

> Any developer who gets upset at a patch not
> getting in during a code slush needs to chill out.

I'd say that any developer that gets upset because things are horribly
inefficient is in his good right :-)..... *expecting a slam dunk on
the head*

> >  - Development doesn't stop just every time a release is coming up.
>
> You're wrong to say that development stops during
> a code slush.  It doesn't -

Right, but there's absolutely no guarantee that those patches will
ever come back.

Developers might
 - forget about it because they've found another way which doesn't
require their fix or enhanced functionality
 - crash on a tropical island with a lot of girls, but unfortunately no internet
 - go on extended vacation, in which case it's just an unwanted delay
in Wine's progress
 - have a thousand other reasons to not care anymore (that's not
necessarily because they're angry).

> the developers keep improving their new
> feature while waiting for the slush to be over.

Yes.  But if their patches were actually *applied*, other developers
could test their changes and everything would speed up a great deal,
in theory at least.

> > - Developers can actively select whether they'd like to help with the
> > release (switch to '0.9-rc' branch) or do a little more crazy stuff
> > (switch to trunk).
>
> They can already do that; just apply the patches you're interested in.

More monkey work for the individual developer?

> >  - Only sane patches get accepted to the RC by picking and merging
> > those that are approved some way or another.
>
> Feel free to maintain an alternate tree which QA's proposed
> patches not yet in the main tree.  There are several folks who
> do this for the linux kernel.

Fair 'nuff.  Point taken.

> > - Patches don't get "LOST" as you call it..
>
> Again, the only reason a patch might get lost is because
> the author of the patch didn't follow protocol, and retransmit
> his patch periodically.

That does not make it less of a problem for Wine.
The patch would still be lost, no?

> Molle, you seem to want to fix a lot of 'process' things
> in wine that aren't broken.

I never said broken!
I'm saying that from a newcomers fantastically objective POV, there
might be a more efficient way than what everybody here's used to.  And
I do appreciate that you take time to tell me why I'm wrong.  Thanks!

> How about focusing on
> actually fixing bugs, instead of telling us how to work?

Nah, less fun.

Just kidding!

I know that the new guy who spews fancy ideas right and left which
requires the old guys to change some part of how they work is not
welcome.  I do apologize for being such a PITA for you guys.

I hope on the other hand that, IF it's not just me that doesn't
understand a perfectly good process, but there's actual room for
improvement, that you'll take some of the ideas seriously.

And I *AM* trying to chip in, I'm *not* spending all my Wine time
complaining.  Hope you don't think that I do.  I really don't!

But I have a full time job and a very large todo list.  I can't afford
to spend all my time on Wine.  Nothing really goes as fast as I'd
like.