diff options
Diffstat (limited to 'doc/FAQ_DEV')
| -rw-r--r-- | doc/FAQ_DEV | 391 |
1 files changed, 201 insertions, 190 deletions
diff --git a/doc/FAQ_DEV b/doc/FAQ_DEV index 1cb4fda82f0..5a6f5e8685b 100644 --- a/doc/FAQ_DEV +++ b/doc/FAQ_DEV @@ -1,7 +1,7 @@ Developer's Frequently Asked Questions (FAQ) for PostgreSQL - Last updated: Tue Dec 4 01:14:35 EST 2001 + Last updated: Tue Dec 4 01:20:03 EST 2001 Current maintainer: Bruce Momjian (pgman@candle.pha.pa.us) @@ -446,210 +446,221 @@ typedef struct nameData 15) How are RPM's packaged? This was written by Lamar Owen: -2001-05-03 - -As to how the RPMs are built -- to answer that question sanely requires -me to know how much experience you have with the whole RPM paradigm. -'How is the RPM built?' is a multifaceted question. The obvious simple -answer is that I maintain: - 1.) A set of patches to make certain portions of the source - tree 'behave' in the different environment of the RPMset; - 2.) The initscript; - 3.) Any other ancilliary scripts and files; - 4.) A README.rpm-dist document that tries to adequately document - both the differences between the RPM build and the WHY of the - differences, as well as useful RPM environment operations - (like, using syslog, upgrading, getting postmaster to - start at OS boot, etc); - 5.) The spec file that throws it all together. This is not a - trivial undertaking in a package of this size. - -I then download and build on as many different canonical distributions -as I can -- currently I am able to build on Red Hat 6.2, 7.0, and 7.1 on -my personal hardware. Occasionally I receive opportunity from certain -commercial enterprises such as Great Bridge and PostgreSQL, Inc. to -build on other distributions. - -I test the build by installing the resulting packages and running the -regression tests. Once the build passes these tests, I upload to the -postgresql.org ftp server and make a release announcement. I am also -responsible for maintaining the RPM download area on the ftp site. - -You'll notice I said 'canonical' distributions above. That simply means -that the machine is as stock 'out of the box' as practical -- that is, -everything (except select few programs) on these boxen are installed by -RPM; only official Red Hat released RPMs are used (except in unusual -circumstances involving software that will not alter the build -- for -example, installing a newer non-RedHat version of the Dia diagramming -package is OK -- installing Python 2.1 on the box that has Python 1.5.2 -installed is not, as that alters the PostgreSQL build). The RPM as -uploaded is built to as close to out-of-the-box pristine as is -possible. Only the standard released 'official to that release' -compiler is used -- and only the standard official kernel is used as -well. - -For a time I built on Mandrake for RedHat consumption -- no more. -Nonstandard RPM building systems are worse than useless. Which is not -to say that Mandrake is useless! By no means is Mandrake useless -- -unless you are building Red Hat RPMs -- and Red Hat is useless if you're -trying to build Mandrake or SuSE RPMs, for that matter. But I would be -foolish to use 'Lamar Owen's Super Special RPM Blend Distro 0.1.2' to -build for public consumption! :-) - -I _do_ attempt to make the _source_ RPM compatible with as many -distributions as possible -- however, since I have limited resources (as -a volunteer RPM maintainer) I am limited as to the amount of testing -said build will get on other distributions, architectures, or systems. - -And, while I understand people's desire to immediately upgrade to the -newest version, realize that I do this as a side interest -- I have a -regular, full-time job as a broadcast -engineer/webmaster/sysadmin/Technical Director which occasionally -prevents me from making timely RPM releases. This happened during the -early part of the 7.1 beta cycle -- but I believe I was pretty much on -the ball for the Release Candidates and the final release. - -I am working towards a more open RPM distribution -- I would dearly love -to more fully document the process and put everything into CVS -- once I -figure out how I want to represent things such as the spec file in a CVS -form. It makes no sense to maintain a changelog, for instance, in the -spec file in CVS when CVS does a better job of changelogs -- I will need -to write a tool to generate a real spec file from a CVS spec-source file -that would add version numbers, changelog entries, etc to the result -before building the RPM. IOW, I need to rethink the process -- and then -go through the motions of putting my long RPM history into CVS one -version at a time so that version history information isn't lost. - -As to why all these files aren't part of the source tree, well, unless -there was a large cry for it to happen, I don't believe it should. -PostgreSQL is very platform-agnostic -- and I like that. Including the -RPM stuff as part of the Official Tarball (TM) would, IMHO, slant that -agnostic stance in a negative way. But maybe I'm too sensitive to -that. I'm not opposed to doing that if that is the consensus of the -core group -- and that would be a sneaky way to get the stuff into CVS -:-). But if the core group isn't thrilled with the idea (and my -instinct says they're not likely to be), I am opposed to the idea -- not -to keep the stuff to myself, but to not hinder the platform-neutral -stance. IMHO, of course. - -Of course, there are many projects that DO include all the files -necessary to build RPMs from their Official Tarball (TM). - + + 2001-05-03 + + As to how the RPMs are built -- to answer that question sanely + requires me to know how much experience you have with the whole RPM + paradigm. 'How is the RPM built?' is a multifaceted question. The + obvious simple answer is that I maintain: + + 1.) A set of patches to make certain portions of the source tree + 'behave' in the different environment of the RPMset; + + 2.) The initscript; + + 3.) Any other ancilliary scripts and files; + + 4.) A README.rpm-dist document that tries to adequately document both + the differences between the RPM build and the WHY of the differences, + as well as useful RPM environment operations (like, using syslog, + upgrading, getting postmaster to start at OS boot, etc); + + 5.) The spec file that throws it all together. This is not a trivial + undertaking in a package of this size. + + I then download and build on as many different canonical distributions + as I can -- currently I am able to build on Red Hat 6.2, 7.0, and 7.1 + on my personal hardware. Occasionally I receive opportunity from + certain commercial enterprises such as Great Bridge and PostgreSQL, + Inc. to build on other distributions. + + I test the build by installing the resulting packages and running the + regression tests. Once the build passes these tests, I upload to the + postgresql.org ftp server and make a release announcement. I am also + responsible for maintaining the RPM download area on the ftp site. + + You'll notice I said 'canonical' distributions above. That simply + means that the machine is as stock 'out of the box' as practical -- + that is, everything (except select few programs) on these boxen are + installed by RPM; only official Red Hat released RPMs are used (except + in unusual circumstances involving software that will not alter the + build -- for example, installing a newer non-RedHat version of the Dia + diagramming package is OK -- installing Python 2.1 on the box that has + Python 1.5.2 installed is not, as that alters the PostgreSQL build). + The RPM as uploaded is built to as close to out-of-the-box pristine as + is possible. Only the standard released 'official to that release' + compiler is used -- and only the standard official kernel is used as + well. + + For a time I built on Mandrake for RedHat consumption -- no more. + Nonstandard RPM building systems are worse than useless. Which is not + to say that Mandrake is useless! By no means is Mandrake useless -- + unless you are building Red Hat RPMs -- and Red Hat is useless if + you're trying to build Mandrake or SuSE RPMs, for that matter. But I + would be foolish to use 'Lamar Owen's Super Special RPM Blend Distro + 0.1.2' to build for public consumption! :-) + + I _do_ attempt to make the _source_ RPM compatible with as many + distributions as possible -- however, since I have limited resources + (as a volunteer RPM maintainer) I am limited as to the amount of + testing said build will get on other distributions, architectures, or + systems. + + And, while I understand people's desire to immediately upgrade to the + newest version, realize that I do this as a side interest -- I have a + regular, full-time job as a broadcast + engineer/webmaster/sysadmin/Technical Director which occasionally + prevents me from making timely RPM releases. This happened during the + early part of the 7.1 beta cycle -- but I believe I was pretty much on + the ball for the Release Candidates and the final release. + + I am working towards a more open RPM distribution -- I would dearly + love to more fully document the process and put everything into CVS -- + once I figure out how I want to represent things such as the spec file + in a CVS form. It makes no sense to maintain a changelog, for + instance, in the spec file in CVS when CVS does a better job of + changelogs -- I will need to write a tool to generate a real spec file + from a CVS spec-source file that would add version numbers, changelog + entries, etc to the result before building the RPM. IOW, I need to + rethink the process -- and then go through the motions of putting my + long RPM history into CVS one version at a time so that version + history information isn't lost. + + As to why all these files aren't part of the source tree, well, unless + there was a large cry for it to happen, I don't believe it should. + PostgreSQL is very platform-agnostic -- and I like that. Including the + RPM stuff as part of the Official Tarball (TM) would, IMHO, slant that + agnostic stance in a negative way. But maybe I'm too sensitive to + that. I'm not opposed to doing that if that is the consensus of the + core group -- and that would be a sneaky way to get the stuff into CVS + :-). But if the core group isn't thrilled with the idea (and my + instinct says they're not likely to be), I am opposed to the idea -- + not to keep the stuff to myself, but to not hinder the + platform-neutral stance. IMHO, of course. + + Of course, there are many projects that DO include all the files + necessary to build RPMs from their Official Tarball (TM). + 16) How are CVS branches managed? This was written by Tom Lane: -2001-05-07 - -If you just do basic "cvs checkout", "cvs update", "cvs commit", then -you'll always be dealing with the HEAD version of the files in CVS. -That's what you want for development, but if you need to patch past -stable releases then you have to be able to access and update the -"branch" portions of our CVS repository. We normally fork off a branch -for a stable release just before starting the development cycle for the -next release. - -The first thing you have to know is the branch name for the branch you -are interested in getting at. To do this, look at some long-lived file, -say the top-level HISTORY file, with "cvs status -v" to see what the -branch names are. (Thanks to Ian Lance Taylor for pointing out that -this is the easiest way to do it.) Typical branch names are: - + + 2001-05-07 + + If you just do basic "cvs checkout", "cvs update", "cvs commit", then + you'll always be dealing with the HEAD version of the files in CVS. + That's what you want for development, but if you need to patch past + stable releases then you have to be able to access and update the + "branch" portions of our CVS repository. We normally fork off a branch + for a stable release just before starting the development cycle for + the next release. + + The first thing you have to know is the branch name for the branch you + are interested in getting at. To do this, look at some long-lived + file, say the top-level HISTORY file, with "cvs status -v" to see what + the branch names are. (Thanks to Ian Lance Taylor for pointing out + that this is the easiest way to do it.) Typical branch names are: REL7_1_STABLE REL7_0_PATCHES REL6_5_PATCHES -OK, so how do you do work on a branch? By far the best way is to create -a separate checkout tree for the branch and do your work in that. Not -only is that the easiest way to deal with CVS, but you really need to -have the whole past tree available anyway to test your work. (And you -*better* test your work. Never forget that dot-releases tend to go out -with very little beta testing --- so whenever you commit an update to a -stable branch, you'd better be doubly sure that it's correct.) - -Normally, to checkout the head branch, you just cd to the place you -want to contain the toplevel "pgsql" directory and say - + OK, so how do you do work on a branch? By far the best way is to + create a separate checkout tree for the branch and do your work in + that. Not only is that the easiest way to deal with CVS, but you + really need to have the whole past tree available anyway to test your + work. (And you *better* test your work. Never forget that dot-releases + tend to go out with very little beta testing --- so whenever you + commit an update to a stable branch, you'd better be doubly sure that + it's correct.) + + Normally, to checkout the head branch, you just cd to the place you + want to contain the toplevel "pgsql" directory and say cvs ... checkout pgsql -To get a past branch, you cd to whereever you want it and say - + To get a past branch, you cd to whereever you want it and say cvs ... checkout -r BRANCHNAME pgsql -For example, just a couple days ago I did - + For example, just a couple days ago I did mkdir ~postgres/REL7_1 cd ~postgres/REL7_1 cvs ... checkout -r REL7_1_STABLE pgsql -and now I have a maintenance copy of 7.1.*. - -When you've done a checkout in this way, the branch name is "sticky": -CVS automatically knows that this directory tree is for the branch, -and whenever you do "cvs update" or "cvs commit" in this tree, you'll -fetch or store the latest version in the branch, not the head version. -Easy as can be. - -So, if you have a patch that needs to apply to both the head and a -recent stable branch, you have to make the edits and do the commit -twice, once in your development tree and once in your stable branch -tree. This is kind of a pain, which is why we don't normally fork -the tree right away after a major release --- we wait for a dot-release -or two, so that we won't have to double-patch the first wave of fixes. - + and now I have a maintenance copy of 7.1.*. + + When you've done a checkout in this way, the branch name is "sticky": + CVS automatically knows that this directory tree is for the branch, + and whenever you do "cvs update" or "cvs commit" in this tree, you'll + fetch or store the latest version in the branch, not the head version. + Easy as can be. + + So, if you have a patch that needs to apply to both the head and a + recent stable branch, you have to make the edits and do the commit + twice, once in your development tree and once in your stable branch + tree. This is kind of a pain, which is why we don't normally fork the + tree right away after a major release --- we wait for a dot-release or + two, so that we won't have to double-patch the first wave of fixes. + 17) How go I get involved in PostgreSQL development? This was written by Lamar Owen: -2001-06-22 - -> If someone was interested in joining the development team, where would -> they... -> - Find a description of the open source development process used by the -> PostgreSQL team. - -Read HACKERS for six months (or a full release cycle, whichever is longer). -Really. HACKERS _is_the process. The process is not well documented (AFAIK --- it may be somewhere that I am not aware of) -- and it changes continually. - -> - Find the development environment (OS, system, compilers, etc) -> required to develop code. - -Developers Corner on the website -has links to this information. The distribution tarball itself -includes all the extra tools and documents that go beyond a good -Unix-like development environment. In general, a modern unix with a -modern gcc, GNU make or equivalent, autoconf (of a particular version), -and good working knowledge of those tools are required. - -> - Find an area or two that needs some support. - -The TODO list. - -You've made the first step, by finding and subscribing to HACKERS. Once you -find an area to look at in the TODO, and have read the documentation on the -internals, etc, then you check out a current CVS,write what you are going to -write (keeping your CVS checkout up to date in the process), and make up a -patch (as a context diff only) and send to the PATCHES list, prefereably. - -Discussion on the patch typically happens here. If the patch adds a major -feature, it would be a good idea to talk about it first on the HACKERS list, -in order to increase the chances of it being accepted, as well as toavoid -duplication of effort. Note that experienced developers with a proven track -record usually get the big jobs -- for more than one reason. Also note that -PostgreSQL is highly portable -- nonportable code will likely be dismissed -out of hand. - -Once your contributions get accepted, things move from there. Typically, you -would be added as a developer on the list on the website when one of the -other developers recommends it. Membership on the steering committee is by -invitation only, by the other steering committee members, from what I have -gathered watching froma distance. - -I make these statements from having watched the process for over two years. - -To see a good example of how one goes about this, search the archives for the -name 'Tom Lane' and see what his first post consisted of, and where he took -things. In particular, note that this hasn't been _that_ long ago -- and his -bugfixing and general deep knowledge with this codebase is legendary. Take a -few days to read after him. And pay special attention to both the sheer -quantity as well as the painstaking quality of his work. Both are in high -demand. + + 2001-06-22 + + > If someone was interested in joining the development team, where + would + > they... + > - Find a description of the open source development process used by + the + > PostgreSQL team. + + Read HACKERS for six months (or a full release cycle, whichever is + longer). Really. HACKERS _is_the process. The process is not well + documented (AFAIK -- it may be somewhere that I am not aware of) -- + and it changes continually. + + > - Find the development environment (OS, system, compilers, etc) + > required to develop code. + + Developers Corner on the website has links to this information. The + distribution tarball itself includes all the extra tools and documents + that go beyond a good Unix-like development environment. In general, a + modern unix with a modern gcc, GNU make or equivalent, autoconf (of a + particular version), and good working knowledge of those tools are + required. + + > - Find an area or two that needs some support. + + The TODO list. + + You've made the first step, by finding and subscribing to HACKERS. + Once you find an area to look at in the TODO, and have read the + documentation on the internals, etc, then you check out a current + CVS,write what you are going to write (keeping your CVS checkout up to + date in the process), and make up a patch (as a context diff only) and + send to the PATCHES list, prefereably. + + Discussion on the patch typically happens here. If the patch adds a + major feature, it would be a good idea to talk about it first on the + HACKERS list, in order to increase the chances of it being accepted, + as well as toavoid duplication of effort. Note that experienced + developers with a proven track record usually get the big jobs -- for + more than one reason. Also note that PostgreSQL is highly portable -- + nonportable code will likely be dismissed out of hand. + + Once your contributions get accepted, things move from there. + Typically, you would be added as a developer on the list on the + website when one of the other developers recommends it. Membership on + the steering committee is by invitation only, by the other steering + committee members, from what I have gathered watching froma distance. + + I make these statements from having watched the process for over two + years. + + To see a good example of how one goes about this, search the archives + for the name 'Tom Lane' and see what his first post consisted of, and + where he took things. In particular, note that this hasn't been _that_ + long ago -- and his bugfixing and general deep knowledge with this + codebase is legendary. Take a few days to read after him. And pay + special attention to both the sheer quantity as well as the + painstaking quality of his work. Both are in high demand. |