1
1
2
2
Developer's Frequently Asked Questions (FAQ) for PostgreSQL
3
3
4
- Last updated:Fri Jun 9 21:54:54 EDT 2000
4
+ Last updated:Mon Nov 26 21:48:19 EST 2001
5
5
6
6
Current maintainer: Bruce Momjian (pgman@candle.pha.pa.us)
7
7
30
30
14) Why don't we use threads in the backend?
31
31
15) How are RPM's packaged?
32
32
16) How are CVS branches handled?
33
+ 17) How do I get involved in PostgreSQL development?
33
34
_________________________________________________________________
34
35
35
36
1) What tools are available for developers?
@@ -444,22 +445,22 @@ typedef struct nameData
444
445
445
446
15) How are RPM's packaged?
446
447
447
- Thisis from Lamar Owen:
448
+ Thiswas written by Lamar Owen:
448
449
As to how the RPMs are built -- to answer that question sanely requires
449
450
me to know how much experience you have with the whole RPM paradigm.
450
451
'How is the RPM built?' is a multifaceted question. The obvious simple
451
452
answer is that I maintain:
452
- 1.) A set of patches to make certain portions of the source
453
- tree 'behave' in the different environment of the RPMset;
454
- 2.) The initscript;
455
- 3.) Any other ancilliary scripts and files;
456
- 4.) A README.rpm-dist document that tries to adequately document
457
- both the differences between the RPM build and the WHY of the
458
- differences, as well as useful RPM environment operations
459
- (like, using syslog, upgrading, getting postmaster to
460
- start at OS boot, etc);
461
- 5.) The spec file that throws it all together. This is not a
462
- trivial undertaking in a package of this size.
453
+ 1.) A set of patches to make certain portions of the source
454
+ tree 'behave' in the different environment of the RPMset;
455
+ 2.) The initscript;
456
+ 3.) Any other ancilliary scripts and files;
457
+ 4.) A README.rpm-dist document that tries to adequately document
458
+ both the differences between the RPM build and the WHY of the
459
+ differences, as well as useful RPM environment operations
460
+ (like, using syslog, upgrading, getting postmaster to
461
+ start at OS boot, etc);
462
+ 5.) The spec file that throws it all together. This is not a
463
+ trivial undertaking in a package of this size.
463
464
464
465
I then download and build on as many different canonical distributions
465
466
as I can -- currently I am able to build on Red Hat 6.2, 7.0, and 7.1 on
@@ -582,9 +583,9 @@ snapshot whereas a branch is a changeable fileset.) Rule of thumb is
582
583
that names attached to four-number versions where the third number is
583
584
zero represent branches, the others are just tags. Here we can see that
584
585
the extant branches are
585
- REL7_1_STABLE
586
- REL7_0_PATCHES
587
- REL6_5_PATCHES
586
+ REL7_1_STABLE
587
+ REL7_0_PATCHES
588
+ REL6_5_PATCHES
588
589
The next commit to the head will be revision 1.107, whereas any changes
589
590
committed into the REL7_1_STABLE branch will have revision numbers like
590
591
1.106.2.*, corresponding to the branch number 1.106.0.2 (don't ask where
@@ -601,17 +602,17 @@ stable branch, you'd better be doubly sure that it's correct.)
601
602
Normally, to checkout the head branch, you just cd to the place you
602
603
want to contain the toplevel "pgsql" directory and say
603
604
604
- cvs ... checkout pgsql
605
+ cvs ... checkout pgsql
605
606
606
607
To get a past branch, you cd to whereever you want it and say
607
608
608
- cvs ... checkout -r BRANCHNAME pgsql
609
+ cvs ... checkout -r BRANCHNAME pgsql
609
610
610
611
For example, just a couple days ago I did
611
612
612
- mkdir ~postgres/REL7_1
613
- cd ~postgres/REL7_1
614
- cvs ... checkout -r REL7_1_STABLE pgsql
613
+ mkdir ~postgres/REL7_1
614
+ cd ~postgres/REL7_1
615
+ cvs ... checkout -r REL7_1_STABLE pgsql
615
616
616
617
and now I have a maintenance copy of 7.1.*.
617
618
@@ -630,3 +631,58 @@ or two, so that we won't have to double-patch the first wave of fixes.
630
631
631
632
Also, Ian Lance Taylor points out that branches and tags can be
632
633
distiguished by using "cvs status -v".
634
+
635
+ 17) How go I get involved in PostgreSQL development?
636
+
637
+ This was written by Lamar Owen:
638
+ > If someone was interested in joining the development team, where would
639
+ > they...
640
+ > - Find a description of the open source development process used by the
641
+ > PostgreSQL team.
642
+
643
+ Read HACKERS for six months (or a full release cycle, whichever is longer).
644
+ Really. HACKERS _is_the process. The process is not well documented (AFAIK
645
+ -- it may be somewhere that I am not aware of) -- and it changes continually.
646
+
647
+ > - Find the development environment (OS, system, compilers, etc)
648
+ > required to develop code.
649
+
650
+ Developers Corner on the website has links to this information. The
651
+ distribution tarball itself includes all the extra tools and documents that
652
+ go beyond a good Unix-like development environment. In general, a modern
653
+ unix with a modern gcc, GNU make or equivalent, autoconf (of a particular
654
+ version), and good working knowledge of those tools are required.
655
+
656
+ > - Find an area or two that needs some support.
657
+
658
+ The TODO list.
659
+
660
+ You've made the first step, by finding and subscribing to HACKERS. Once you
661
+ find an area to look at in the TODO, and have read the documentation on the
662
+ internals, etc, then you check out a current CVS,write what you are going to
663
+ write (keeping your CVS checkout up to date in the process), and make up a
664
+ patch (as a context diff only) and send to the PATCHES list, prefereably.
665
+
666
+ Discussion on the patch typically happens here. If the patch adds a major
667
+ feature, it would be a good idea to talk about it first on the HACKERS list,
668
+ in order to increase the chances of it being accepted, as well as toavoid
669
+ duplication of effort. Note that experienced developers with a proven track
670
+ record usually get the big jobs -- for more than one reason. Also note that
671
+ PostgreSQL is highly portable -- nonportable code will likely be dismissed
672
+ out of hand.
673
+
674
+ Once your contributions get accepted, things move from there. Typically, you
675
+ would be added as a developer on the list on the website when one of the
676
+ other developers recommends it. Membership on the steering committee is by
677
+ invitation only, by the other steering committee members, from what I have
678
+ gathered watching froma distance.
679
+
680
+ I make these statements from having watched the process for over two years.
681
+
682
+ To see a good example of how one goes about this, search the archives for the
683
+ name 'Tom Lane' and see what his first post consisted of, and where he took
684
+ things. In particular, note that this hasn't been _that_ long ago -- and his
685
+ bugfixing and general deep knowledge with this codebase is legendary. Take a
686
+ few days to read after him. And pay special attention to both the sheer
687
+ quantity as well as the painstaking quality of his work. Both are in high
688
+ demand.