Re: PostgreSQL Developer meeting minutes up

Hi,

Andrew Dunstan wrote:
> One fact to keep in mind is that, unlike most other FOSS projects, we
> keep quite a large number of branches live.

So far I thought exactly that would be a good reason for migrating to
something like git. Those claim to ease working on multiple branches in
parallel, and in my experience that works pretty well. I'd like to find
a good way to allow the Postgres project to make use of these features
to ease development.

> 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.

I agree and appreciate that very much as well.

> The question we often face in backpatching is not "where did it first
> occur?" but "how far back should we patch it?".

Uh.. the difference here mostly being *when* the question comes up,
right? Because the possible answers "in 8.1" or "back to 8.1" are pretty
close.

From what I understand now, you are saying here that you work on the
patch and only after that question how far back to apply it. Note that
working on the patch doesn't necessarily mean having to commit it on
HEAD first. I seem to recall a script which has so far been used for CVS
to do the multi-branch commits pretty much at the same time. Is that
correct?

> 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.

I'll give these a try with one of the touted merge algorithms. I'm
curious myself.

> 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.

Well, my experience with the Postgres-R patch has been different.
However, that patch is probably not overly invasive.

> Most of this stuff is almost invisible to most of the community.

The daily work maybe, yes. But not the end result, which is known as
rock-solid. I certainly don't want to change that. ;-)

Regards

Markus Wanner