"Thomas G. Lockhart" <lockhart@alumni.caltech.edu> writes:
> Personally, I would choose to post patches, since as you point out we
> are really focused on v6.5beta. We *still* need a patch convention with
> a .../patches/ directory shipped with Postgres, and with routines to
> help create and apply the patches.
The trouble with maintaining a pile of independent patches is that you
have cross-patch dependencies: patch B fails to apply unless patch A
was previously installed, or applies but fails to work right, etc etc.
Worse, an installation reporting a problem might be running a slightly
different set of patches than anyone else, complicating the diagnosis
substantially.
So, while tossing a patch into a "patches" directory sounds easy,
I fear it will lead to more effort overall, both for developers and
users. It also doesn't advance the goal of creating super-stable
versions for people who have chosen to run a back revision for
reliability reasons.
I think the approach already discussed is better: apply bug fixes
(but not feature additions) to the previous release's CVS branch
whenever practical, and put out a dot-N version every so often.
> I would suggest that for the future we create a top level directory
> called "patches", and within that directory have two routines, perhaps
> CreatePatch, CreatePackage, and ApplyPatch.
This would be worth doing in order to simplify life for people working
on the code --- it'd be easier to package up and mail in a set of
changes, and easier to apply them. But I don't think it's an answer
for back-rev maintenance.
regards, tom lane