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