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