[ros-dev] Re: [ros-diffs] [gdalsnes] 17607: mostly naming changes

[Casper Hornstrup]

> -----Original Message-----
> From: ros-dev-bounces at reactos.com [mailto:ros-dev-bounces at reactos.com] On Behalf Of Alex Ionescu
> Sent: 3. september 2005 00:07
> To: ros-dev at reactos.com
> Subject: [ros-dev] Re: [ros-diffs] [gdalsnes] 17607: mostly naming changes
> 
> This is as of now, I think the 4th or 5th gigantic patch in this branch with
> 1) Dubious changes
> 2) Changes stuck together (naming changes with code changes, etc)
> 3) Still no changelog.
> 
> I am voicing my public disagreement/outcry with the way this branch is
> being handled.

I also have to express my concerns about the extremely large changes made
to this branch. We now build ISO's of each revision. This has the (major)
benefit that we can track down the exact revision that cause a particular
regression without needing to build a lot of ISO's manually. If however,
it turns out that the bug was introduced with a 14.000 line change, you
still have to look at this huge diff to locate the bug. Humans are very
poor at keeping track of this much information so it would require a
considerable amount of time to locate the bug in such a large diff. We
are still very bad at not introducing regressions so we have a lot of
them. At least we should try to develop ReactOS so that the causes of
the regressions are easy to locate and fix.
Assume there is 1 bug per 1000 line change on average. Now this 14.000
line change will contain 14 bugs. How much time is required to locate
the bugs in the diff? Quite a lot, I would imagine. Wouldn't it be more
fun if you could spot the bugs just from reading the diff so you
don't have to waste countless hours of your time with a debugger?
Had it been 14 changes of 1000 lines then this would have been possible
(although 1000 lines is still a lot of information to keep track of,
but it's doable). There would still be 14 bugs, but they would be
spread over several 1000 line changes and some changes might even not
have any bugs, in which case the information to look through is cut
down even further.

Casper