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