in reply to Code Inspections in Open Source projects

In a recent effort at code review on an Open Source C++ project I had some difficulties that eventually drove me away from the project. I would find something that could be easily re factored to fix a bug (one documented in the code itself) but was not allowed to fix it because it had originally been the way I proposed and then at some point had been changed. The svn entry for the change didn't mention why (but did mention the bug it introduced), but since no one could remember why the code was the way it was, they weren't willing to change it. I know that came out kind of garbled but the crux is that no one knew the code well enough to explain why it was written with the bug in it in the first place, and they where afraid fixing that bug would introduce a worse bug. So in this case I'm not sure what to think, just figured I'd share my miserable experience and ask if anyone else had similar cases and how they combat that? I'm sure its related to the pride (i wrote it that way so it should stay that way even if it added a bug) but I'm really kinda clueless. Eventually (very very soon after starting with the project) it drove me away from the project entirely.


___________
Eric Hodges
  • Comment on Re: Code Inspections in Open Source projects

Replies are listed 'Best First'.
Re^2: Code Inspections in Open Source projects
by ysth (Canon) on Jan 18, 2008 at 00:43 UTC