Re: [HACKERS] v6.4.3 ?
От | The Hermit Hacker |
---|---|
Тема | Re: [HACKERS] v6.4.3 ? |
Дата | |
Msg-id | Pine.BSF.4.05.9902092320350.41941-100000@thelab.hub.org обсуждение исходный текст |
Ответ на | Re: [HACKERS] v6.4.3 ? (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-hackers |
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
В списке pgsql-hackers по дате отправления: