Re: PostgreSQL Developer meeting minutes up

Markus Wanner <markus(at)bluegap(dot)ch> writes:
> Out of interest, and not necessarily related to Postgres: why do you
> think it's unreasonable? Fixing the problem where it was introduced
> sounds like the most reasonable place to fix it, IMO.

There are a number of possible reasons, but here are a few that hold for me:

* I always prefer to isolate a bug in HEAD if possible. It's the
version of the code that's most familiar at the moment, and there are
often new features available that make it easier to test a problem.
So that generally leads to formulating the fix in terms of the HEAD code
first. After that you start to think about whether (some form of) the
bug exists in back branches and how to fix those branches.

* Experience has shown that later branches tend to have more places
affected by an issue than older ones; eg you might need to touch four
places to fix a bug now, but only three of those places exist in the
older branches. ISTM you'd be far more likely to miss fixing the
fourth place if you do your initial investigation and fixing/testing
in the oldest affected branch.

* We want HEAD to have the cleanest, most maintainable version of the
fix. It's not infrequently the case that the most natural way of fixing
a problem varies across branches --- for instance, there might be a
helpful subroutine available in later branches. If you design the fix
in terms of what works in the oldest branch that has the problem,
you're more likely to come up with something that's suboptimal for later
branches. For instance in the helpful-subroutine case, I'd be more
likely to decide to back-port the subroutine along with the fix if
I work from HEAD back than if I try to work the other way.

* We are often willing to adopt a fairly invasive fix for HEAD, if
that's what's needed to have a clean maintainable solution, and then
look for a less invasive but klugy solution for the back branches.
Approaching it the other way around would strongly encourage use of
the kluge solution as a permanent fix.

So there are a lot of good reasons to work backwards in patching.
I don't believe that these would be outweighed by some advantage
in the mechanics of applying an unchanging patch to multiple
branches (especially since AFAICT the mechanical advantage would
be pretty darn minimal anyhow).

regards, tom lane