1212< H1 > Developer's Frequently Asked Questions (FAQ) for
1313 PostgreSQL</ H1 >
1414
15- < P > Last updated: Tue Dec 4 01:14:35 EST 2001</ P >
15+ < P > Last updated: Tue Dec 4 01:20:03 EST 2001</ P >
1616
1717
1818< P > Current maintainer: Bruce Momjian (< A href =
@@ -549,37 +549,38 @@ <H3><A name="14">14</A>) Why don't we use threads in the
549549< H3 > < A name ="15 "> 15</ A > ) How are RPM's packaged?</ H3 >
550550
551551< P > This was written by Lamar Owen:</ P >
552- < PRE >
553- 2001-05-03
552+ < P > 2001-05-03
554553
555- As to how the RPMs are built -- to answer that question sanely requires
554+ < P > As to how the RPMs are built -- to answer that question sanely requires
556555me to know how much experience you have with the whole RPM paradigm.
557556'How is the RPM built?' is a multifaceted question. The obvious simple
558557answer is that I maintain:
558+
559+ < P >
559560 1.) A set of patches to make certain portions of the source
560561 tree 'behave' in the different environment of the RPMset;
561- 2.) The initscript;
562- 3.) Any other ancilliary scripts and files;
563- 4.) A README.rpm-dist document that tries to adequately document
562+ < P > 2.) The initscript;
563+ < P > 3.) Any other ancilliary scripts and files;
564+ < P > 4.) A README.rpm-dist document that tries to adequately document
564565 both the differences between the RPM build and the WHY of the
565566 differences, as well as useful RPM environment operations
566567 (like, using syslog, upgrading, getting postmaster to
567568 start at OS boot, etc);
568- 5.) The spec file that throws it all together. This is not a
569+ < P > 5.) The spec file that throws it all together. This is not a
569570 trivial undertaking in a package of this size.
570571
571- I then download and build on as many different canonical distributions
572+ < P > I then download and build on as many different canonical distributions
572573as I can -- currently I am able to build on Red Hat 6.2, 7.0, and 7.1 on
573574my personal hardware. Occasionally I receive opportunity from certain
574575commercial enterprises such as Great Bridge and PostgreSQL, Inc. to
575576build on other distributions.
576577
577- I test the build by installing the resulting packages and running the
578+ < P > I test the build by installing the resulting packages and running the
578579regression tests. Once the build passes these tests, I upload to the
579580postgresql.org ftp server and make a release announcement. I am also
580581responsible for maintaining the RPM download area on the ftp site.
581582
582- You'll notice I said 'canonical' distributions above. That simply means
583+ < P > You'll notice I said 'canonical' distributions above. That simply means
583584that the machine is as stock 'out of the box' as practical -- that is,
584585everything (except select few programs) on these boxen are installed by
585586RPM; only official Red Hat released RPMs are used (except in unusual
@@ -592,28 +593,28 @@ <H3><A name="15">15</A>) How are RPM's packaged?</H3>
592593compiler is used -- and only the standard official kernel is used as
593594well.
594595
595- For a time I built on Mandrake for RedHat consumption -- no more.
596+ < P > For a time I built on Mandrake for RedHat consumption -- no more.
596597Nonstandard RPM building systems are worse than useless. Which is not
597598to say that Mandrake is useless! By no means is Mandrake useless --
598599unless you are building Red Hat RPMs -- and Red Hat is useless if you're
599600trying to build Mandrake or SuSE RPMs, for that matter. But I would be
600601foolish to use 'Lamar Owen's Super Special RPM Blend Distro 0.1.2' to
601602build for public consumption! :-)
602603
603- I _do_ attempt to make the _source_ RPM compatible with as many
604+ < P > I _do_ attempt to make the _source_ RPM compatible with as many
604605distributions as possible -- however, since I have limited resources (as
605606a volunteer RPM maintainer) I am limited as to the amount of testing
606607said build will get on other distributions, architectures, or systems.
607608
608- And, while I understand people's desire to immediately upgrade to the
609+ < P > And, while I understand people's desire to immediately upgrade to the
609610newest version, realize that I do this as a side interest -- I have a
610611regular, full-time job as a broadcast
611612engineer/webmaster/sysadmin/Technical Director which occasionally
612613prevents me from making timely RPM releases. This happened during the
613614early part of the 7.1 beta cycle -- but I believe I was pretty much on
614615the ball for the Release Candidates and the final release.
615616
616- I am working towards a more open RPM distribution -- I would dearly love
617+ < P > I am working towards a more open RPM distribution -- I would dearly love
617618to more fully document the process and put everything into CVS -- once I
618619figure out how I want to represent things such as the spec file in a CVS
619620form. It makes no sense to maintain a changelog, for instance, in the
@@ -624,7 +625,7 @@ <H3><A name="15">15</A>) How are RPM's packaged?</H3>
624625go through the motions of putting my long RPM history into CVS one
625626version at a time so that version history information isn't lost.
626627
627- As to why all these files aren't part of the source tree, well, unless
628+ < P > As to why all these files aren't part of the source tree, well, unless
628629there was a large cry for it to happen, I don't believe it should.
629630PostgreSQL is very platform-agnostic -- and I like that. Including the
630631RPM stuff as part of the Official Tarball (TM) would, IMHO, slant that
@@ -636,132 +637,146 @@ <H3><A name="15">15</A>) How are RPM's packaged?</H3>
636637to keep the stuff to myself, but to not hinder the platform-neutral
637638stance. IMHO, of course.
638639
639- Of course, there are many projects that DO include all the files
640+ < P > Of course, there are many projects that DO include all the files
640641necessary to build RPMs from their Official Tarball (TM).
641- </ PRE >
642642
643643< H3 > < A name ="16 "> 16</ A > ) How are CVS branches managed?</ H3 >
644644
645645< P > This was written by Tom Lane:</ P >
646- < PRE >
646+ < P >
6476472001-05-07
648648
649- If you just do basic "cvs checkout", "cvs update", "cvs commit", then
649+ < P > If you just do basic "cvs checkout", "cvs update", "cvs commit", then
650650you'll always be dealing with the HEAD version of the files in CVS.
651651That's what you want for development, but if you need to patch past
652652stable releases then you have to be able to access and update the
653653"branch" portions of our CVS repository. We normally fork off a branch
654654for a stable release just before starting the development cycle for the
655655next release.
656656
657- The first thing you have to know is the branch name for the branch you
657+ < P > The first thing you have to know is the branch name for the branch you
658658are interested in getting at. To do this, look at some long-lived file,
659659say the top-level HISTORY file, with "cvs status -v" to see what the
660660branch names are. (Thanks to Ian Lance Taylor for pointing out that
661661this is the easiest way to do it.) Typical branch names are:
662662
663+ < PRE >
663664 REL7_1_STABLE
664665 REL7_0_PATCHES
665666 REL6_5_PATCHES
667+ </ PRE >
666668
667- OK, so how do you do work on a branch? By far the best way is to create
669+ < P > OK, so how do you do work on a branch? By far the best way is to create
668670a separate checkout tree for the branch and do your work in that. Not
669671only is that the easiest way to deal with CVS, but you really need to
670672have the whole past tree available anyway to test your work. (And you
671673*better* test your work. Never forget that dot-releases tend to go out
672674with very little beta testing --- so whenever you commit an update to a
673675stable branch, you'd better be doubly sure that it's correct.)
674676
675- Normally, to checkout the head branch, you just cd to the place you
677+ < P > Normally, to checkout the head branch, you just cd to the place you
676678want to contain the toplevel "pgsql" directory and say
677679
680+ < PRE >
678681 cvs ... checkout pgsql
682+ </ PRE >
679683
680- To get a past branch, you cd to whereever you want it and say
684+ < P > To get a past branch, you cd to whereever you want it and say
681685
686+ < PRE >
682687 cvs ... checkout -r BRANCHNAME pgsql
688+ </ PRE >
683689
684- For example, just a couple days ago I did
690+ < P > For example, just a couple days ago I did
685691
692+ < PRE >
686693 mkdir ~postgres/REL7_1
687694 cd ~postgres/REL7_1
688695 cvs ... checkout -r REL7_1_STABLE pgsql
696+ </ PRE >
689697
690- and now I have a maintenance copy of 7.1.*.
698+ < P > and now I have a maintenance copy of 7.1.*.
691699
692- When you've done a checkout in this way, the branch name is "sticky":
700+ < P > When you've done a checkout in this way, the branch name is "sticky":
693701CVS automatically knows that this directory tree is for the branch,
694702and whenever you do "cvs update" or "cvs commit" in this tree, you'll
695703fetch or store the latest version in the branch, not the head version.
696704Easy as can be.
697705
698- So, if you have a patch that needs to apply to both the head and a
706+ < P > So, if you have a patch that needs to apply to both the head and a
699707recent stable branch, you have to make the edits and do the commit
700708twice, once in your development tree and once in your stable branch
701709tree. This is kind of a pain, which is why we don't normally fork
702710the tree right away after a major release --- we wait for a dot-release
703711or two, so that we won't have to double-patch the first wave of fixes.
704- </ PRE >
705712
706713< H3 > < A name ="17 "> 17</ A > ) How go I get involved in PostgreSQL
707714 development?</ H3 >
708715< P > This was written by Lamar Owen:</ P >
709- < PRE >
716+ < P >
7107172001-06-22
711718
719+ < P >
712720> If someone was interested in joining the development team, where would
721+ < BR >
713722> they...
723+ < BR >
714724> - Find a description of the open source development process used by the
725+ < BR >
715726> PostgreSQL team.
727+ < BR >
716728
717- Read HACKERS for six months (or a full release cycle, whichever is longer).
729+ < P > Read HACKERS for six months (or a full release cycle, whichever is longer).
718730Really. HACKERS _is_the process. The process is not well documented (AFAIK
719731-- it may be somewhere that I am not aware of) -- and it changes continually.
720732
733+ < P >
721734> - Find the development environment (OS, system, compilers, etc)
735+ < BR >
722736> required to develop code.
737+ < BR >
723738
724- < a href ="developers.postgresql.org "> Developers Corner</ a > on the website
739+ < P > < a href ="developers.postgresql.org "> Developers Corner</ a > on the website
725740has links to this information. The distribution tarball itself
726741includes all the extra tools and documents that go beyond a good
727742Unix-like development environment. In general, a modern unix with a
728743modern gcc, GNU make or equivalent, autoconf (of a particular version),
729744and good working knowledge of those tools are required.
730745
746+ < P >
731747> - Find an area or two that needs some support.
748+ < BR >
732749
733- The TODO list.
750+ < P > The TODO list.
734751
735- You've made the first step, by finding and subscribing to HACKERS. Once you
752+ < P > You've made the first step, by finding and subscribing to HACKERS. Once you
736753find an area to look at in the TODO, and have read the documentation on the
737754internals, etc, then you check out a current CVS,write what you are going to
738755write (keeping your CVS checkout up to date in the process), and make up a
739756patch (as a context diff only) and send to the PATCHES list, prefereably.
740757
741- Discussion on the patch typically happens here. If the patch adds a major
758+ < P > Discussion on the patch typically happens here. If the patch adds a major
742759feature, it would be a good idea to talk about it first on the HACKERS list,
743760in order to increase the chances of it being accepted, as well as toavoid
744761duplication of effort. Note that experienced developers with a proven track
745762record usually get the big jobs -- for more than one reason. Also note that
746763PostgreSQL is highly portable -- nonportable code will likely be dismissed
747764out of hand.
748765
749- Once your contributions get accepted, things move from there. Typically, you
766+ < P > Once your contributions get accepted, things move from there. Typically, you
750767would be added as a developer on the list on the website when one of the
751768other developers recommends it. Membership on the steering committee is by
752769invitation only, by the other steering committee members, from what I have
753770gathered watching froma distance.
754771
755- I make these statements from having watched the process for over two years.
772+ < P > I make these statements from having watched the process for over two years.
756773
757- To see a good example of how one goes about this, search the archives for the
774+ < P > To see a good example of how one goes about this, search the archives for the
758775name 'Tom Lane' and see what his first post consisted of, and where he took
759776things. In particular, note that this hasn't been _that_ long ago -- and his
760777bugfixing and general deep knowledge with this codebase is legendary. Take a
761778few days to read after him. And pay special attention to both the sheer
762779quantity as well as the painstaking quality of his work. Both are in high
763780demand.
764- </ PRE >
765-
766781</ BODY >
767782</ HTML >