[haiku-commits] Re: r35757 - haiku/trunk/src/add-ons/kernel/partitioning_systems/intel

  • From: Ingo Weinhold <ingo_weinhold@xxxxxx>
  • To: haiku-commits@xxxxxxxxxxxxx
  • Date: Thu, 04 Mar 2010 14:53:25 +0100

On 2010-03-04 at 13:08:49 [+0100], Stephan Assmus <superstippi@xxxxxx> wrote:
> On 2010-03-04 at 10:20:31 [+0100], Ingo Weinhold <ingo_weinhold@xxxxxx> 
> wrote:
> > BTW, generally I'm not very fond of the development strategy to apply 
> > fixes
> > before understanding a problem.
> Basically, I just wanted to be able to boot Haiku after upgrading. Instead 
> of
> just applying the fix locally, I thought it's better to commit it, so that
> whoever has a clue what change may have caused this -- either who worked on
> it last or who has an understanding of the code -- is becomming aware of the
> problem. I know it would be nice if I digged into the code to understand
> what's happening, but chances are I would waste precious time, while the
> effect of me commiting the quick fix *could* make somebody else go "yes, of
> course!"...

Without a ticket or at least a TODO and probably no one who feels primarily 
responsible (I wrote the module initially and I don't; Axel introduced the 
variable block size support; Michael made the most recent changes) there's a 
good chance that this will simply slip by.

> What's so bad about commiting a two line fix if the worst that
> can happen is that nobody else cares?

Let me play devil's advocate: The 0 block size causes a partition's offset to 
be computed incorrectly which causes the user's data to be overwritten at a 
later point. The change, by preventing the early crash, enables the 
destructive behavior.

Yes, unlikely scenario, but that's not my point anyway. Symptom-fixing is 
just poor development practice that lowers the code quality.

CU, Ingo

Other related posts: