Re: [HACKERS] v6.4.3 ?
От | Tom Lane |
---|---|
Тема | Re: [HACKERS] v6.4.3 ? |
Дата | |
Msg-id | 2167.918577561@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: [HACKERS] v6.4.3 ? ("Thomas G. Lockhart" <lockhart@alumni.caltech.edu>) |
Ответы |
Re: [HACKERS] v6.4.3 ?
Re: [HACKERS] v6.4.3 ? |
Список | pgsql-hackers |
"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
В списке pgsql-hackers по дате отправления: