Thursday, October 13, 2005, 6:06:33 PM, Robert Reif wrote:
Add DirectSoundFullDuplex support.
This patch is rather large because it was necessary to refactor the existing code so it could be used by the full duplex code. Most of the changes are either changing all the code to use the lower level device objects rather than the higher level COM objects or moving code and renaming variables to make things easier to follow. This has the benefit of removing one level of indirection for a lot of code. With this refactoring, it was very easy to add the full duplex support.
There should be no functional changes to capture and playback other than a slight speed improvement due to one less level of indirection for accessing most variables.
1. Don't send patches in gz - only plain text is accepted here. ;) 2. This is not a good time for this changes (code freeze is still in affect).
Find some bugs in bugzilla to fix <g>
Vitaliy.
Vitaliy Margolen wrote:
- Don't send patches in gz - only plain text is accepted here. ;)
- This is not a good time for this changes (code freeze is still in affect).
Find some bugs in bugzilla to fix <g>
Vitaliy.
I guess I could have split it up into half a dozen patches.
This is something I needed for work so I took the opportunity to do some wine hacking. I'm way to busy to do much more than just reading the mailing lists now and I don't see that changing for the next 6 months. This can wait until after 0.9. It's out there now for anyone that is interested.
I do most of my development on RH9 for RH9 and most of the sound related bugs and missing features are either ALSA related (even OSS emulation in ALSA) or scheduler related and I don't have the time or resources to tackle big issues like these now.
Le jeudi 13 octobre 2005 à 21:29 -0400, Robert Reif a écrit :
I guess I could have split it up into half a dozen patches.
This is something I needed for work so I took the opportunity to do some wine hacking. I'm way to busy to do much more than just reading the mailing lists now and I don't see that changing for the next 6 months. This can wait until after 0.9. It's out there now for anyone that is interested.
I do most of my development on RH9 for RH9 and most of the sound related bugs and missing features are either ALSA related (even OSS emulation in ALSA) or scheduler related and I don't have the time or resources to tackle big issues like these now.
Your patch look very good to me (but i'm not an expert). If nobody thinks that it has issues, maybe you could resend it uncompressed and splitted into two or more parts (at least separate the refactoring part and the full duplex part). Then Alexandre will decide if it can be applied before or after the 0.9 release.
Thanks !
Vitaliy Margolen wrote:
- This is not a good time for this changes (code freeze is still in affect).
Find some bugs in bugzilla to fix <g>
I'm getting a sick feeling to my stomach here. Maybe I'm just misunderstanding things?
You're rejecting a perfectly fine patch to Wine, because it's the wrong season of the year to send good patches?
What was wrong with doing what everyone else does - - create a branch for the up-and-coming release, - keep applying good patches to trunk, - cherry pick *very* important patches (clean bugfixes) and merge them to the branch?
?
People tell me that Wine are always two steps behind. Doesn't surprise a lot, if perfectly fine patches are rejected from entering development trunk.
What's the idea here, to make sure that CrossOver and Cedega are always a good step ahead? Do they have too little business value to keep sales up if Wine is allowed to develop too fast? Or what's going on?
Molle Bestefich wrote:
I'm getting a sick feeling to my stomach here. Maybe I'm just misunderstanding things?
You're rejecting a perfectly fine patch to Wine, because it's the wrong season of the year to send good patches?
People tell me that Wine are always two steps behind. Doesn't surprise a lot, if perfectly fine patches are rejected from entering development trunk.
What's the idea here, to make sure that CrossOver and Cedega are always a good step ahead? Do they have too little business value to keep sales up if Wine is allowed to develop too fast? Or what's going on?
Which is actually quite an interesting question...I mean, Wine is quite good and works for many applications, but what is the business model of CrossOver and others, when and if Wine gets so good and CrossOver isn't needed anymore?
Does CrossOver have a plan, such as offering services, instead of selling CrossOver? And because Wine is licensed under LGPL (correct me if I'm wrong!!), it allows CrossOver and others to develop and sell their implementations of Wine, without submitting back patches to the Wine sources.
I don't mean to attack here CrossOver and it's widely known, that CrossOver's support of Wine, including patches, is great! But some clarification would be in place...
Regards
Signer: Eddy Nigg Company: StartCom Linux at www.startcom.org http://www.startcom.org/ MediaHost^(TM) at www.mediahost.org http://www.mediahost.org/ Skype: startcom callto://startcom/ Phone: +1.213.341.0390
Import StartCom Public CA http://cert.startcom.org/index.php?app=109
On 10/14/05, Molle Bestefich molle.bestefich@gmail.com wrote:
Vitaliy Margolen wrote:
- This is not a good time for this changes (code freeze is still in
affect).
Find some bugs in bugzilla to fix <g>
I'm getting a sick feeling to my stomach here. Maybe I'm just misunderstanding things?
You're rejecting a perfectly fine patch to Wine, because it's the wrong season of the year to send good patches?
No, just deferring it.
What was wrong with doing what everyone else does -
- create a branch for the up-and-coming release,
- keep applying good patches to trunk,
- cherry pick *very* important patches (clean bugfixes) and merge
them to the branch?
Go look at what the Linux Kernel and the gcc projects *actually* do. Both projects actually do have this kind of code "slush" periodically. Active development continues during the slush periods, but the resulting patches just sit in the developers' trees until after the slush is over.
It's ok, really. - Dan
Friday, October 14, 2005, 5:24:40 AM, Molle Bestefich wrote:
Vitaliy Margolen wrote:
- This is not a good time for this changes (code freeze is still in affect).
Find some bugs in bugzilla to fix <g>
I'm getting a sick feeling to my stomach here. Maybe I'm just misunderstanding things?
I think you do.
You're rejecting a perfectly fine patch to Wine, because it's the wrong season of the year to send good patches?
I have no power to accept nor reject path. All I'm trying to say, is that right now (Oct 14 2005) Wine is in a "code freeze" (see announcement about that few weeks ago). That announcement stated that only "small bug fixes" or other well warranted "small changes" will go in until after Wine 0.9 is out. And they will probably get lost and will have to be resent.
Don't get me wrong here - I am excited as you are about some one working on dsound. It's just a wrong time to send this huge patches in.
Also if you haven't looked, there are lots of open bugs in bugzilla that sooner or later have to be fixed.
Vitaliy
Vitaliy Margolen wrote:
You're rejecting a perfectly fine patch to Wine, because it's the wrong season of the year to send good patches?
I have no power to accept nor reject path. All I'm trying to say, is that right now (Oct 14 2005) Wine is in a "code freeze" (see announcement about that few weeks ago). That announcement stated that only "small bug fixes" or other well warranted "small changes" will go in until after Wine 0.9 is out. And they will probably get lost and will have to be resent.
Don't get me wrong here - I am excited as you are about some one working on dsound. It's just a wrong time to send this huge patches in.
Also if you haven't looked, there are lots of open bugs in bugzilla that sooner or later have to be fixed.
Ok, I did misunderstand a bit, but also you didn't answer my main question. I'll just ask it again, hope it's ok:
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. - Development doesn't stop just every time a release is coming up. - 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). - Only sane patches get accepted to the RC by picking and merging those that are approved some way or another. - Patches don't get "LOST" as you call it..
Cons: - Can't think of any?
Molle Bestefich wrote:
Pros:
- Developers of patches will not get pissed (ahem) for their stuff
not getting in.
- Development doesn't stop just every time a release is coming up.
- 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).
- Only sane patches get accepted to the RC by picking and merging
those that are approved some way or another.
- Patches don't get "LOST" as you call it..
Cons:
- Can't think of any?
Ok, maybe there's one. You need a release manager to pick which patches gets in the RC / release.
But there must be a million ways of doing that automatically, besides from having an actual release manager. Script your way out of it. Automatically merge patches with 'bugfix' or 'Release-Ok' in commit text. Automatically merge patches < 100 lines long. Hohum. Whatever. I can think of more, I'm sure you can too.
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.
[I can the rest ... there is just one real point I need to make here.]
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!
We work this way for quite some time and the speed of development was only hindered by the number of developers involved and patches submitted up to now.
It was never hindered by the number of patches applied.
Ciao, Marcus
On Fri, 14 Oct 2005, Molle Bestefich wrote: [...]
Ok, maybe there's one. You need a release manager to pick which patches gets in the RC / release.
But there must be a million ways of doing that automatically, besides from having an actual release manager. Script your way out of it. Automatically merge patches with 'bugfix' or 'Release-Ok' in commit text. Automatically merge patches < 100 lines long. Hohum. Whatever. I can think of more, I'm sure you can too.
Ok, so all this amounts to committing patches to a stable branch without review while the branches to the unstable tip would still be reviewed and subject to the approval of Alexandre. Why does this sound contradictory???
I you want a stable branch you need a release manager/committee, you cannot automate that part.
Molle Bestefich wrote:
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.
- Development doesn't stop just every time a release is coming up.
- 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).
- Only sane patches get accepted to the RC by picking and merging
those that are approved some way or another.
- Patches don't get "LOST" as you call it..
Cons:
- Can't think of any?
Cons:
- No Programmers and CVS users actually test the RC branch, and keep plunking away at the trunk. - Programmers continue to concentrate on adding unimplemented features instead of fixing existing bugs, since there's no active pushback on new features.
-J
Friday, October 14, 2005, 8:29:19 AM, Molle Bestefich wrote:
Vitaliy Margolen wrote:
You're rejecting a perfectly fine patch to Wine, because it's the wrong season of the year to send good patches?
I have no power to accept nor reject path. All I'm trying to say, is that right now (Oct 14 2005) Wine is in a "code freeze" (see announcement about that few weeks ago). That announcement stated that only "small bug fixes" or other well warranted "small changes" will go in until after Wine 0.9 is out. And they will probably get lost and will have to be resent.
Don't get me wrong here - I am excited as you are about some one working on dsound. It's just a wrong time to send this huge patches in.
Also if you haven't looked, there are lots of open bugs in bugzilla that sooner or later have to be fixed.
Ok, I did misunderstand a bit, but also you didn't answer my main question. I'll just ask it again, hope it's ok:
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.
- Development doesn't stop just every time a release is coming up.
- 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).
- Only sane patches get accepted to the RC by picking and merging
those that are approved some way or another.
- Patches don't get "LOST" as you call it..
Cons:
- Can't think of any?
Again that's not in my power to decide. But I would say - not a good time to branch Wine. It's not stable enough to have "stable" and "development" branches. All fixes are important. And lots of fixes are additional features. It's something different from the rest of the projects. Wine has a some-what cleat target of where it needs to be and what it have to do. Given that target keeps moving all different directions and it's hard to hit it all the time ;)
Vitaliy
Hi,
On Fri, Oct 14, 2005 at 08:51:06AM -0600, Vitaliy Margolen wrote:
Again that's not in my power to decide. But I would say - not a good time to branch Wine. It's not stable enough to have "stable" and "development" branches. All fixes are important. And lots of fixes are additional features. It's something different from the rest of the projects. Wine has a some-what cleat target of where it needs to be and what it have to do. Given that target keeps moving all different directions and it's hard to hit it all the time ;)
Vitaliy
Exactly. That's the very special case that Wine has - it is a rather incomplete clone of the original, as such there will *always* be problems with the code base, no matter how far we get. I.e. it's not simply a matter of disallowing further enhancement work that currently doesn't *need* to be available of some OSS project to reach a certain development state required for the current release. In Wine's case, that enhancement usually *is* needed since Windows provides it and programs *expect* it.
That's why I think that it's not a good idea to boldly reject any and all enhancing patches during that period. Instead, it should simply be made clear that it's not the best thing to spend your development time on currently, and that the preferred way is to do bug database work or program testing.
I.e. *prefer* this direction, not make it exclusive. This could also be done by telling a developer "please no more enhancements now" after he has done one patch too many within our "code freeze" period... (i.e. allow a certain amount of enhancements within this time as long as many other people are actively doing bug-fixing only)
Andreas Mohr
Am Freitag, den 14.10.2005, 16:29 +0200 schrieb Molle Bestefich:
Why not do this: Accept the patches into trunk, and do the "code freeze" in a branch.
Cons:
- Can't think of any?
Most Developer are doing the same as before: Working on there Patches. The Code-Freeze and the Stabilisation-Affect are going to "no-op". Review the Patches most done twice.
I'm waiting for some Patches to come into cvs, but we have to respect the code-freeze.
Hi Vitaliy,
The message error i gave in the bug report is actually all what Wine gives me... I can provided you with a detailed trace, but i don't know what switches to use.
Can you please tell me what's necessary for you to investigate, and i'll do my best.
Regards, Sebastien.
-
Andreas Mohr -
Dan Kegel -
Detlef Riekenberg -
Evil -
Francois Gouget -
Jonathan Ernst -
Marcus Meissner -
MediaHost (TM) -
Molle Bestefich -
Robert Reif -
Sebastien Fievet -
Vitaliy Margolen