[DSOUND] add DirectSoundFullDuplex support
molle.bestefich at gmail.com
Fri Oct 14 10:08:09 CDT 2005
> > 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
> > - 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.
- 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.
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
More information about the wine-devel