Re: PostgreSQL Developer meeting minutes up

Markus Wanner wrote:
> Hi,
>
> Andrew Dunstan wrote:
>
>> Yeah, a requirement to work from the back branch forward is quite
>> unacceptable IMNSHO. It's also quite unreasonable.
>>
>
> The monotone page about daggy fixes does quite a good job in explaining
> why it is helpful. I think it's how to make best use of these tools. And
> it's obviously not the same as what worked well in practice with CVS.
> 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.
>
>
>

Half the trouble with this discussion is that it has not been related
enough to how the Postgres project actually works IMNSHO.

One fact to keep in mind is that, unlike most other FOSS projects, we
keep quite a large number of branches live. If we don't remove one (and
so far there is no great reason to that I know of) that number will be
seven when we release 8.4. There is a huge benefit from this to the user
community. It means that they can deploy Postgres with confidence that
they will not have to upgrade for quite a few years. In the corporate
world, especially, that is a major issue. I occasionally have clients
running 7.4 or even older versions. Anyway, the large number of branches
alone means that our patterns are unlikely to match those of other
projects.

The question we often face in backpatching is not "where did it first
occur?" but "how far back should we patch it?". Problems are almost
always discovered near the top of the version list, overwhelmingly on
the HEAD or most recent stable branches. So the way we work is not to
try to develop a fix where the problem first occurred (which might not
even be on a supported branch at all) but as high up the list as the
problem goes (usually HEAD) and then work out how far down the list to
apply the fix. And the notion that a fix of any complexity at all is
going to be simply applicable across six or seven branches simply defies
our experience. It almost never does. Frequently it won't apply cleanly
from *any* one branch to another. Even fairly trivial patches can suffer
from this: the pretty small plperl fixes I applied yesterday and the day
before, required adjustment going from one branch to the previous one in
about three out of five back branch cases. Sometimes these adjustments
are small, sometimes they are quite large. So the idea that we can just
create a fix on say, the 7.4 branch, and then just merge it forward
nicely, is just fanciful in most cases, as well as being contrary to our
methods of work.

Most of this stuff is almost invisible to most of the community. But
people like Tom work with it every day. And we want to keep Tom
productive, right? ;-)

cheers

andrew