Skip to content

P
Postgres FD Implementation
Commit e0a5d6ce authored by Bruce Momjian's avatar Bruce Momjian
Browse files
Options

Update FAQ_DEV.

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