On Tue, 9 Feb 1999, Tom Lane wrote:
> "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 kinda agree with this one also...as Tom's says, at least ppl can't say
"Patch B broke things", but they didn't apply Patch A, which B's fixes
used features from...
Marc G. Fournier
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org