Markus Wanner <mar...@bluegap.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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers