From: | "Thomas G(dot) Lockhart" <lockhart(at)alumni(dot)caltech(dot)edu> |
---|---|
To: | Bruce Momjian <maillist(at)candle(dot)pha(dot)pa(dot)us> |
Cc: | Michael_Meskes(at)topmail(dot)de, pgsql-hackers(at)postgreSQL(dot)org |
Subject: | Re: [HACKERS] v6.4.3 ? |
Date: | 1999-02-09 14:51:24 |
Message-ID: | 36C04B6C.CAD9A977@alumni.caltech.edu |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
> We can't just do 6.4.2 patches, can we? That would be nice. We
> getting near starting beta, and will not have lots of time to test
> things.
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.
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. CreatePatch would create a
subdirectory, look for all .orig files and make separate patch files for
each inside the subdirectory. Type a README and post a tar file of the
subdirectory at ftp://postgresql.org/pub/patches/. On the other end,
ApplyPatch could print the README, prompt for an "OK to continue?", and
apply the specified patches.
If there is already a common package for doing this we could use that of
course.
I might have time to do this for v6.5 unless someone else wants to give
it a shot. I have some code which could form the basis for this (and I
know that Bruce has something in the source tree which he uses but which
imho does not have enough of the features mentioned above; my current
code is lacking some of these also)...
- Tom
From | Date | Subject | |
---|---|---|---|
Next Message | Thomas G. Lockhart | 1999-02-09 14:55:00 | Re: [HACKERS] VACUUM ANALYZE problem on linux |
Previous Message | Peter T Mount | 1999-02-09 13:56:11 | Re: AW: [HACKERS] Problems with >2GB tables on Linux 2.0 |