As codebases get larger, what is being done to ensure that code reviews are done? I mean I hear second hand about the mean comments from Linus Torvalds about RC code quality in Linux all the time. To paraphrase him, RC code should not have as many kernel breaking bugs as they do. And this is in Linux which has a lot of eyes. What about smaller teams?
Lack of automated testing? If passing some static tests was mandatory for commits to be accepted they could easily have picked up things like debug output left in or functions that always return true.
AFAIK this was all new code which would not have been exercised by existing functional tests. Best case, a static analysis tool might have flagged something but in that case a human would have had to intervene to interpret the results.
From what I can tell is an outsider who runs an open source project that is pretty old at this point, this was a breakdown in procedure by a single developer. the code should have been on a branch or made available for public review by some means. It never should have been committed to the master in the shape it was in.
There is the unfortunate side issue of pressure from the funding sponsor for the work. Along with any personal issues the developer had.
In the end, this was caught. And the code will get a lot of eyes on it. I'm not sure why they didn't start with the OpenBSD port in the beginning though. Much better starting point and more likely to have had fewer bugs introduced by the porting process.
Larger question of code quality (Score:5, Interesting)
Re: (Score:2)
Lack of automated testing? If passing some static tests was mandatory for commits to be accepted they could easily have picked up things like debug output left in or functions that always return true.
Re: Larger question of code quality (Score:3)
AFAIK this was all new code which would not have been exercised by existing functional tests. Best case, a static analysis tool might have flagged something but in that case a human would have had to intervene to interpret the results.
From what I can tell is an outsider who runs an open source project that is pretty old at this point, this was a breakdown in procedure by a single developer. the code should have been on a branch or made available for public review by some means. It never should have been committed to the master in the shape it was in.
There is the unfortunate side issue of pressure from the funding sponsor for the work. Along with any personal issues the developer had.
In the end, this was caught. And the code will get a lot of eyes on it. I'm not sure why they didn't start with the OpenBSD port in the beginning though. Much better starting point and more likely to have had fewer bugs introduced by the porting process.