[ros-dev] Regression fixing
jimtabor.rosdev at gmail.com
Wed Apr 28 23:40:09 CEST 2010
On Wed, Apr 28, 2010 at 7:41 AM, Aleksey Bragin <aleksey at reactos.org> wrote:
> as you all know we have quite a lot of regressions recently, and recently
> they only add up to one another causing annoyances of testers and
> developers. There is a strong need to change this situation as soon as
> possible, otherwise the project's future is undetermined.
> I want to propose a step-by-step approach. Our brave testing team has
> created a good overview of the most important regressions and bugs we have
> so far: http://www.reactos.org/wiki/Buglist .
> Now, very important(!):
> For the first step I would like ALL developers to drop their current
> ReactOS-related work, including all work in branches or wherever else and
> focus ONLY on fixing regressions from that list. The goal is to fix all
> confirmed regressions that have been introduced, starting from the most
> recent and going down to the most ancient. All possible ways to remove a
> regression could be used: starting from a proper fix and finishing with a
> total revert or commenting out even good code.
> Process coordination: feel free to commit proper fixes right away, however
> as for reverts, I, and/or comittee of our core devs, would like to have a
> final say on whether something should be reverted.
Oh yes that works! No one asked me first, even after posting to debug
logs before the reverts!
Like I've posted before, reverting still does not fix the issue since
the issue was not fixed in the first place!
> I repeat, all other non-regression related commits to the official ReactOS
> SVN repository are forbidden, even to branches. The only exception may be
> developers whose access is restricted to branches only.
> Thank you for understanding,
> Aleksey Bragin.
If you really want to fix this mess! First do some research, assume
the code that was working before it was broken is correct. Trust me
this does works from trial and error! Find out from your research what
caused the breakage, that would be from data reduction testing by
revision to revision. Instead of reverting, try something new, like
fixing it. I know it is very hard work and this was what I was doing
for ten years here but to do it right you have to do research and
study. Example: wine...
Reverting things retrogrades the project since those changes are now
lost. Lost information is always lost and never comes back. Not in the
source is still not in the source.
More information about the Ros-dev