[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:
