small vs thorough fixes for bugs

[Martin Pool]

We had some discussion today about the question of fixing bugs on the
surface rather than thoroughly, and whether we get the right balance.
Taking the smallest step that improves the situation is good, but we
also want to be fixing thing systematically and making future changes
earlier.

Here are some braindump notes:

Why don't we fix bugs more thoroughly?
* Changes from new developers who don't know
* Don't understand the problem well enough from fixing just as single bug:
  may be improved by fixing several bugs consecutively in a single area
* Fear we might break something without noticing: addressed by strong tests
* Larger changes may be rejected in review:
  may be improved by talking about the proposed changes first
* Large patches may get reviewed more slowly
* Higher latency to get the original bug fix in, because of repeated reviews
* Feeling of time pressure to get the original bugs fixed
* Should refactorings be separate patches coming in first or later?
* Fixing up API deprecations or compatibility is annoying; pressure to just
  live with suboptimal APIs: may be improved by stable branches, but more
  may be needed
* Large changes can't land to the stable branch
* Fear that the refactoring branch just adds complexity if it's not used later
  on: may cause
* Seeming randomness/inconsistency in reviews:
  - different reviewers have different views on what kind of change is ok
  - perhaps recommend more discussion earlier on, and then refer to that
    by the review
* May be just given vague review feedback "not quite right" or told "your
  approach is completely wrong"
* If you do the larger change after doing the small change, you may just never
  come back to it.

-- 
Martin <http://launchpad.net/~mbp/>