Lots of regressions in games in last few versions

[James McKenzie]

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