James McKenzie wrote:
Vitaliy Margolen wrote:
James McKenzie wrote:
Vitaliy Margolen wrote:
Several latest releases introduced lots and lots of regressions to a point that no games run as-is. Considering that we are at the code freeze, I'd like to see all patches that cause regressions, and all patches that depend on them starting from wine-0.9.58 be reverted.
Also each patch to have a conformance test and statement which games where tested and what problems were fixed with each patch.
Bugs: 13120, 13110, 13101, 13086 and on and on and on.
Can some one explain what's the deal with games not working full screen? Why are there are of the sudden problems with pixel formats? Why lots of games crashing ActivatingContext? Why most games don't work anymore on ATI?
Ya know there is a way to handle this. Bashing developers is not one of them. Regression testing is. Some of our 'users' are not savvy enough
Oh really? So how many regression testing do you need to fix say... bug 11584 Multiple games crash with stack overflow error? 10? 20? 100 (look all the bugs marked as dups of it)? Unless some one actually starts fixing the bug, doing regression testing is pointless. Besides lots of new regressions have regression testing done on them.
There were several 'fixes' to this problem in the issue. And Stephan continues to troubleshoot the problem. However, this is a VOLUNTEER effort and most of us have 'real lives' to live. I would gladly work on rich edit problems as they directly affect a program that I use. However, I don't have enough hours in the day to attempt to work on them. I picked up issue 6254, the lockup problem, and a patch proposed
There are no patches that fix this problem (however hackish they might be). And it looks like a design problem. That's why someone with knowledge of the d3d needs to look at it.
I'd like to trust all developers to make right decisions about what patches are low risk and which have to be tested with loads of apps. But it seems I can't. And no one saying what might break if some patch gets committed. And of course I understand that most things can't be tested with conformance tests there. But at least a minimum of several major titles have to be tested for regressions.
We need to do serious testing before any release. I lived in the QA
Yes everything have to be tested. The business of sending patches that do "the right thing" have to stop. We all know that m$ always does things backwards. And most apps relay on that.
'arena' for many years. However, we do have limited time and we don't have all of the resources we'd like to have. Thus, some problems appear in release code and we have to clean up the mess afterwards. In the
No one should be cleaning up mess. There shouldn't be one in the first place. Or if some one got it in, it should be his responsibility to fix it, or get the whole damn thing out.
case of the issue you pointed out, the simple, but incorrect fix, was to back out the change and then re-introduce it after some major work. This would have delayed the improvement in framerates for many games and productivity programs.
And I tend to disagree with you there. I can point to number of things that weren't right to begin with. And it was clear right from the start. Yet they still not fixed, because now it's not trivial to fix the introduced problems. Or the whole idea was flowed and have to be redone.
And I don't see what's so wrong with having 'git revert' as valid option for any problem patch? If problem is identified and it's not getting fixed before the next release - pull it out. This is the only option with our linear development where we don't have stable and development branches.
Vitaliy
Vitaliy Margolen wrote:
James McKenzie wrote:
There were several 'fixes' to this problem in the issue. And Stephan continues to troubleshoot the problem. However, this is a VOLUNTEER effort and most of us have 'real lives' to live. I would gladly work on rich edit problems as they directly affect a program that I use. However, I don't have enough hours in the day to attempt to work on them. I picked up issue 6254, the lockup problem, and a patch proposed
There are no patches that fix this problem (however hackish they might be). And it looks like a design problem. That's why someone with knowledge of the d3d needs to look at it.
I agree that a D3D expert needs to fix this problem, pronto. However, I'm not one of them and it looks like at least one of them proposed a fix in the issue.
We need to do serious testing before any release. I lived in the QA
Yes everything have to be tested. The business of sending patches that do "the right thing" have to stop. We all know that m$ always does things backwards. And most apps relay on that.
Again, do we have enough time to test every combination of products in the short release to release schedule. I would say NO. However, this schedule is not of my doing. My saying "Release no software before its time" applies in many cases.
'arena' for many years. However, we do have limited time and we don't have all of the resources we'd like to have. Thus, some problems appear in release code and we have to clean up the mess afterwards. In the
No one should be cleaning up mess. There shouldn't be one in the first place. Or if some one got it in, it should be his responsibility to fix it, or get the whole damn thing out.
I agree.
case of the issue you pointed out, the simple, but incorrect fix, was to back out the change and then re-introduce it after some major work. This would have delayed the improvement in framerates for many games and productivity programs.
And I tend to disagree with you there. I can point to number of things that weren't right to begin with. And it was clear right from the start. Yet they still not fixed, because now it's not trivial to fix the introduced problems. Or the whole idea was flowed and have to be redone.
Then we fix it or redesign/rebuild. Our reputations depend on it. The project depends on it. And this is what killed Project Odin.
And I don't see what's so wrong with having 'git revert' as valid option for any problem patch? If problem is identified and it's not getting fixed before the next release - pull it out. This is the only option with our linear development where we don't have stable and development branches.
I agree. We need a stable and development branching. We will need this so we can fix problems in 1.0 and to move towards 1.2. This will make AJs job miserable, but this has to be done in order to keep what is what straight. Would git be up to this task?
James McKenzie
James McKenzie schrieb:
Vitaliy Margolen wrote:
James McKenzie wrote:
[...]
Again, do we have enough time to test every combination of products in the short release to release schedule. I would say NO. However, this schedule is not of my doing. My saying "Release no software before its time" applies in many cases.
basically I would agree with you, but many people do not take a look at it if it is not even 1.0 these days. for normal users it is most of the time not that important if it is 0.9.60 or 1.0, but for a company and decision makers it is. Doing a 1.0 will give popularity and with his comes attention from people wit money, money that they might spend in helping wine to develop faster. I have seen this pattern a few times now. Wine might not be ready to do an excellent job of emulating what windows does, but it is usable, even in production. Good enough for a 1.0.
Ah well.. I am no wine developer ;)
bye blackdrag
Am Sonntag, 11. Mai 2008 05:35:15 schrieb James McKenzie:
I agree that a D3D expert needs to fix this problem, pronto. However, I'm not one of them and it looks like at least one of them proposed a fix in the issue.
Fyi, I am terribly busy at the moment with university work, I have a bunch of deadlines and 5 exams the next weeks. Somewhen between mid-june and the begin of july I'll go to Mineapolis for a few months and will have time to work on Wine again, but I am afraid I won't have much time before that.
Maybe I can look into the ActivateContext recursion, but I can't promise that. It depends on how my other work is going. A start for fixing this issue would be implementing my two-liner change I described a while ago on wine-devel, and then testing it as good as possible to see if it triggers any other bugs. As a second step the tests proposed in the same mail should be implemented to see if all the issues are fixed.
-
James McKenzie -
Jochen -
Stefan Dösinger -
Vitaliy Margolen