database/postgres
database/postgres
1
0
Fork 0
mirror of https://github.com/postgres/postgres.git synced 2025-06-05 23:56:58 +03:00
Code

Update FAQ_DEV.

Browse Source
This commit is contained in:
Bruce Momjian 2001-12-04 06:20:53 +00:00
parent 00836012c6
commit e0a5d6ce46
2 changed files with 390 additions and 366 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

219
doc/FAQ_DEV
View File

@ -1,7 +1,7 @@
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,60 +446,66 @@ 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 As to how the RPMs are built -- to answer that question sanely
me to know how much experience you have with the whole RPM paradigm. requires me to know how much experience you have with the whole RPM
'How is the RPM built?' is a multifaceted question. The obvious simple paradigm. 'How is the RPM built?' is a multifaceted question. The
answer is that I maintain: 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; 1.) A set of patches to make certain portions of the source tree
'behave' in the different environment of the RPMset;
2.) The initscript; 2.) The initscript;
3.) Any other ancilliary scripts and files; 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 4.) A README.rpm-dist document that tries to adequately document both
differences, as well as useful RPM environment operations the differences between the RPM build and the WHY of the differences,
(like, using syslog, upgrading, getting postmaster to as well as useful RPM environment operations (like, using syslog,
start at OS boot, etc); 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. 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 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 as I can -- currently I am able to build on Red Hat 6.2, 7.0, and 7.1
my personal hardware. Occasionally I receive opportunity from certain on my personal hardware. Occasionally I receive opportunity from
commercial enterprises such as Great Bridge and PostgreSQL, Inc. to certain commercial enterprises such as Great Bridge and PostgreSQL,
build on other distributions. Inc. to build on other distributions.
I test the build by installing the resulting packages and running the I test the build by installing the resulting packages and running the
regression tests. Once the build passes these tests, I upload to 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 postgresql.org ftp server and make a release announcement. I am also
responsible for maintaining the RPM download area on the ftp site. responsible for maintaining the RPM download area on the ftp site.
You'll notice I said 'canonical' distributions above. That simply means You'll notice I said 'canonical' distributions above. That simply
that the machine is as stock 'out of the box' as practical -- that is, means that the machine is as stock 'out of the box' as practical --
everything (except select few programs) on these boxen are installed by that is, everything (except select few programs) on these boxen are
RPM; only official Red Hat released RPMs are used (except in unusual installed by RPM; only official Red Hat released RPMs are used (except
circumstances involving software that will not alter the build -- for in unusual circumstances involving software that will not alter the
example, installing a newer non-RedHat version of the Dia diagramming build -- for example, installing a newer non-RedHat version of the Dia
package is OK -- installing Python 2.1 on the box that has Python 1.5.2 diagramming package is OK -- installing Python 2.1 on the box that has
installed is not, as that alters the PostgreSQL build). The RPM as Python 1.5.2 installed is not, as that alters the PostgreSQL build).
uploaded is built to as close to out-of-the-box pristine as is The RPM as uploaded is built to as close to out-of-the-box pristine as
possible. Only the standard released 'official to that release' is possible. Only the standard released 'official to that release'
compiler is used -- and only the standard official kernel is used as compiler is used -- and only the standard official kernel is used as
well. well.
For a time I built on Mandrake for RedHat consumption -- no more. For a time I built on Mandrake for RedHat consumption -- no more.
Nonstandard RPM building systems are worse than useless. Which is not Nonstandard RPM building systems are worse than useless. Which is not
to say that Mandrake is useless! By no means is Mandrake useless -- 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 unless you are building Red Hat RPMs -- and Red Hat is useless if
trying to build Mandrake or SuSE RPMs, for that matter. But I would be you're trying to build Mandrake or SuSE RPMs, for that matter. But I
foolish to use 'Lamar Owen's Super Special RPM Blend Distro 0.1.2' to would be foolish to use 'Lamar Owen's Super Special RPM Blend Distro
build for public consumption! :-) 0.1.2' to build for public consumption! :-)
I _do_ attempt to make the _source_ RPM compatible with as many I _do_ attempt to make the _source_ RPM compatible with as many
distributions as possible -- however, since I have limited resources (as distributions as possible -- however, since I have limited resources
a volunteer RPM maintainer) I am limited as to the amount of testing (as a volunteer RPM maintainer) I am limited as to the amount of
said build will get on other distributions, architectures, or systems. testing said build will get on other distributions, architectures, or
systems.
And, while I understand people's desire to immediately upgrade to the 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 newest version, realize that I do this as a side interest -- I have a
@ -509,16 +515,17 @@ 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 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. the ball for the Release Candidates and the final release.
I am working towards a more open RPM distribution -- I would dearly love I am working towards a more open RPM distribution -- I would dearly
to more fully document the process and put everything into CVS -- once I love to more fully document the process and put everything into CVS --
figure out how I want to represent things such as the spec file in a CVS once I figure out how I want to represent things such as the spec file
form. It makes no sense to maintain a changelog, for instance, in the in a CVS form. It makes no sense to maintain a changelog, for
spec file in CVS when CVS does a better job of changelogs -- I will need instance, in the spec file in CVS when CVS does a better job of
to write a tool to generate a real spec file from a CVS spec-source file changelogs -- I will need to write a tool to generate a real spec file
that would add version numbers, changelog entries, etc to the result from a CVS spec-source file that would add version numbers, changelog
before building the RPM. IOW, I need to rethink the process -- and then entries, etc to the result before building the RPM. IOW, I need to
go through the motions of putting my long RPM history into CVS one rethink the process -- and then go through the motions of putting my
version at a time so that version history information isn't lost. 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 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. there was a large cry for it to happen, I don't believe it should.
@ -528,9 +535,9 @@ 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 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 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 :-). 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 instinct says they're not likely to be), I am opposed to the idea --
to keep the stuff to myself, but to not hinder the platform-neutral not to keep the stuff to myself, but to not hinder the
stance. IMHO, of course. platform-neutral stance. IMHO, of course.
Of course, there are many projects that DO include all the files Of course, there are many projects that DO include all the files
necessary to build RPMs from their Official Tarball (TM). necessary to build RPMs from their Official Tarball (TM).
@ -538,6 +545,7 @@ 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 If you just do basic "cvs checkout", "cvs update", "cvs commit", then
@ -545,38 +553,35 @@ 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 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 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 "branch" portions of our CVS repository. We normally fork off a branch
for a stable release just before starting the development cycle for the for a stable release just before starting the development cycle for
next release. the next release.
The first thing you have to know is the branch name for the branch you 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, are interested in getting at. To do this, look at some long-lived
say the top-level HISTORY file, with "cvs status -v" to see what the file, say the top-level HISTORY file, with "cvs status -v" to see what
branch names are. (Thanks to Ian Lance Taylor for pointing out that the branch names are. (Thanks to Ian Lance Taylor for pointing out
this is the easiest way to do it.) Typical branch names are: 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 Normally, to checkout the head branch, you just cd to the place you
want to contain the toplevel "pgsql" directory and say 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
@ -592,64 +597,70 @@ 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 > If someone was interested in joining the development team, where
would
> they... > they...
> - Find a description of the open source development process used by the > - Find a description of the open source development process used by
the
> PostgreSQL team. > PostgreSQL team.
Read HACKERS for six months (or a full release cycle, whichever is longer). Read HACKERS for six months (or a full release cycle, whichever is
Really. HACKERS _is_the process. The process is not well documented (AFAIK longer). Really. HACKERS _is_the process. The process is not well
-- it may be somewhere that I am not aware of) -- and it changes continually. documented (AFAIK -- it may be somewhere that I am not aware of) --
and it changes continually.
> - Find the development environment (OS, system, compilers, etc) > - Find the development environment (OS, system, compilers, etc)
> required to develop code. > required to develop code.
Developers Corner on the website Developers Corner on the website has links to this information. The
has links to this information. The distribution tarball itself distribution tarball itself includes all the extra tools and documents
includes all the extra tools and documents that go beyond a good that go beyond a good Unix-like development environment. In general, a
Unix-like development environment. In general, a modern unix with a modern unix with a modern gcc, GNU make or equivalent, autoconf (of a
modern gcc, GNU make or equivalent, autoconf (of a particular version), particular version), and good working knowledge of those tools are
and good working knowledge of those tools are required. required.
> - Find an area or two that needs some support. > - Find an area or two that needs some support.
The TODO list. The TODO list.
You've made the first step, by finding and subscribing to HACKERS. Once you You've made the first step, by finding and subscribing to HACKERS.
find an area to look at in the TODO, and have read the documentation on the Once you find an area to look at in the TODO, and have read the
internals, etc, then you check out a current CVS,write what you are going to documentation on the internals, etc, then you check out a current
write (keeping your CVS checkout up to date in the process), and make up a CVS,write what you are going to write (keeping your CVS checkout up to
patch (as a context diff only) and send to the PATCHES list, prefereably. 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 Discussion on the patch typically happens here. If the patch adds a
feature, it would be a good idea to talk about it first on the HACKERS list, major feature, it would be a good idea to talk about it first on the
in order to increase the chances of it being accepted, as well as toavoid HACKERS list, in order to increase the chances of it being accepted,
duplication of effort. Note that experienced developers with a proven track as well as toavoid duplication of effort. Note that experienced
record usually get the big jobs -- for more than one reason. Also note that developers with a proven track record usually get the big jobs -- for
PostgreSQL is highly portable -- nonportable code will likely be dismissed more than one reason. Also note that PostgreSQL is highly portable --
out of hand. nonportable code will likely be dismissed out of hand.
Once your contributions get accepted, things move from there. Typically, you 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 on
invitation only, by the other steering committee members, from what I have the steering committee is by invitation only, by the other steering
gathered watching froma distance. committee members, from what I have gathered watching froma distance.
I make these statements from having watched the process for over two years. 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 To see a good example of how one goes about this, search the archives
name 'Tom Lane' and see what his first post consisted of, and where he took for the name 'Tom Lane' and see what his first post consisted of, and
things. In particular, note that this hasn't been _that_ long ago -- and his where he took things. In particular, note that this hasn't been _that_
bugfixing and general deep knowledge with this codebase is legendary. Take a long ago -- and his bugfixing and general deep knowledge with this
few days to read after him. And pay special attention to both the sheer codebase is legendary. Take a few days to read after him. And pay
quantity as well as the painstaking quality of his work. Both are in high special attention to both the sheer quantity as well as the
demand. painstaking quality of his work. Both are in high demand.

349
doc/src/FAQ/FAQ_DEV.html
View File

@ -14,7 +14,6 @@
<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>
@ -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>As to how the RPMs are built -- to answer that question sanely requires <P>2001-05-03</P>
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 <P>As to how the RPMs are built -- to answer that question sanely
answer is that I maintain: 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:</P>
<P>1.) A set of patches to make certain portions of the source tree
'behave' in the different environment of the RPMset;</P>
<P>2.) The initscript;</P>
<P>3.) Any other ancilliary scripts and files;</P>
<P>
1.) A set of patches to make certain portions of the source
tree 'behave' in the different environment of the RPMset;
<P> 2.) The initscript;
<P> 3.) Any other ancilliary scripts and files;
<P>4.) A README.rpm-dist document that tries to adequately document <P>4.) A README.rpm-dist document that tries to adequately document
both the differences between the RPM build and the WHY of the both the differences between the RPM build and the WHY of the
differences, as well as useful RPM environment operations differences, as well as useful RPM environment operations (like,
(like, using syslog, upgrading, getting postmaster to using syslog, upgrading, getting postmaster to start at OS boot,
start at OS boot, etc); etc);</P>
<P>5.) The spec file that throws it all together. This is not a <P>5.) The spec file that throws it all together. This is not a
trivial undertaking in a package of this size. trivial undertaking in a package of this size.</P>
<P>I then download and build on as many different canonical distributions <P>I then download and build on as many different canonical
as I can -- currently I am able to build on Red Hat 6.2, 7.0, and 7.1 on distributions as I can -- currently I am able to build on Red Hat
my personal hardware. Occasionally I receive opportunity from certain 6.2, 7.0, and 7.1 on my personal hardware. Occasionally I receive
commercial enterprises such as Great Bridge and PostgreSQL, Inc. to opportunity from certain commercial enterprises such as Great
build on other distributions. Bridge and PostgreSQL, Inc. to build on other distributions.</P>
<P>I test the build by installing the resulting packages and running the <P>I test the build by installing the resulting packages and
regression tests. Once the build passes these tests, I upload to the running the regression tests. Once the build passes these tests, I
postgresql.org ftp server and make a release announcement. I am also upload to the postgresql.org ftp server and make a release
responsible for maintaining the RPM download area on the ftp site. announcement. I am also responsible for maintaining the RPM
download area on the ftp site.</P>
<P>You'll notice I said 'canonical' distributions above. That simply means <P>You'll notice I said 'canonical' distributions above. That
that the machine is as stock 'out of the box' as practical -- that is, simply means that the machine is as stock 'out of the box' as
everything (except select few programs) on these boxen are installed by practical -- that is, everything (except select few programs) on
RPM; only official Red Hat released RPMs are used (except in unusual these boxen are installed by RPM; only official Red Hat released
circumstances involving software that will not alter the build -- for RPMs are used (except in unusual circumstances involving software
example, installing a newer non-RedHat version of the Dia diagramming that will not alter the build -- for example, installing a newer
package is OK -- installing Python 2.1 on the box that has Python 1.5.2 non-RedHat version of the Dia diagramming package is OK --
installed is not, as that alters the PostgreSQL build). The RPM as installing Python 2.1 on the box that has Python 1.5.2 installed is
uploaded is built to as close to out-of-the-box pristine as is not, as that alters the PostgreSQL build). The RPM as uploaded is
possible. Only the standard released 'official to that release' built to as close to out-of-the-box pristine as is possible. Only
compiler is used -- and only the standard official kernel is used as the standard released 'official to that release' compiler is used
well. -- and only the standard official kernel is used as well.</P>
<P>For a time I built on Mandrake for RedHat consumption -- no more. <P>For a time I built on Mandrake for RedHat consumption -- no
Nonstandard RPM building systems are worse than useless. Which is not more. Nonstandard RPM building systems are worse than useless.
to say that Mandrake is useless! By no means is Mandrake useless -- Which is not to say that Mandrake is useless! By no means is
unless you are building Red Hat RPMs -- and Red Hat is useless if you're Mandrake useless -- unless you are building Red Hat RPMs -- and Red
trying to build Mandrake or SuSE RPMs, for that matter. But I would be Hat is useless if you're trying to build Mandrake or SuSE RPMs, for
foolish to use 'Lamar Owen's Super Special RPM Blend Distro 0.1.2' to that matter. But I would be foolish to use 'Lamar Owen's Super
build for public consumption! :-) Special RPM Blend Distro 0.1.2' to build for public consumption!
:-)</P>
<P>I _do_ attempt to make the _source_ RPM compatible with as many <P>I _do_ attempt to make the _source_ RPM compatible with as many
distributions as possible -- however, since I have limited resources (as distributions as possible -- however, since I have limited
a volunteer RPM maintainer) I am limited as to the amount of testing resources (as a volunteer RPM maintainer) I am limited as to the
said build will get on other distributions, architectures, or systems. amount of testing said build will get on other distributions,
architectures, or systems.</P>
<P>And, while I understand people's desire to immediately upgrade to the <P>And, while I understand people's desire to immediately upgrade
newest version, realize that I do this as a side interest -- I have a to the newest version, realize that I do this as a side interest --
regular, full-time job as a broadcast I have a regular, full-time job as a broadcast
engineer/webmaster/sysadmin/Technical Director which occasionally engineer/webmaster/sysadmin/Technical Director which occasionally
prevents me from making timely RPM releases. This happened during the prevents me from making timely RPM releases. This happened during
early part of the 7.1 beta cycle -- but I believe I was pretty much on the early part of the 7.1 beta cycle -- but I believe I was pretty
the ball for the Release Candidates and the final release. much on the ball for the Release Candidates and the final
release.</P>
<P>I am working towards a more open RPM distribution -- I would dearly love <P>I am working towards a more open RPM distribution -- I would
to more fully document the process and put everything into CVS -- once I dearly love to more fully document the process and put everything
figure out how I want to represent things such as the spec file in a CVS into CVS -- once I figure out how I want to represent things such
form. It makes no sense to maintain a changelog, for instance, in the as the spec file in a CVS form. It makes no sense to maintain a
spec file in CVS when CVS does a better job of changelogs -- I will need changelog, for instance, in the spec file in CVS when CVS does a
to write a tool to generate a real spec file from a CVS spec-source file better job of changelogs -- I will need to write a tool to generate
that would add version numbers, changelog entries, etc to the result a real spec file from a CVS spec-source file that would add version
before building the RPM. IOW, I need to rethink the process -- and then numbers, changelog entries, etc to the result before building the
go through the motions of putting my long RPM history into CVS one RPM. IOW, I need to rethink the process -- and then go through the
version at a time so that version history information isn't lost. motions of putting my long RPM history into CVS one version at a
time so that version history information isn't lost.</P>
<P>As to why all these files aren't part of the source tree, well, unless <P>As to why all these files aren't part of the source tree, well,
there was a large cry for it to happen, I don't believe it should. unless there was a large cry for it to happen, I don't believe it
PostgreSQL is very platform-agnostic -- and I like that. Including the should. PostgreSQL is very platform-agnostic -- and I like that.
RPM stuff as part of the Official Tarball (TM) would, IMHO, slant that Including the RPM stuff as part of the Official Tarball (TM) would,
agnostic stance in a negative way. But maybe I'm too sensitive to IMHO, slant that agnostic stance in a negative way. But maybe I'm
that. I'm not opposed to doing that if that is the consensus of the too sensitive to that. I'm not opposed to doing that if that is the
core group -- and that would be a sneaky way to get the stuff into CVS consensus of the core group -- and that would be a sneaky way to
:-). But if the core group isn't thrilled with the idea (and my get the stuff into CVS :-). But if the core group isn't thrilled
instinct says they're not likely to be), I am opposed to the idea -- not with the idea (and my instinct says they're not likely to be), I am
to keep the stuff to myself, but to not hinder the platform-neutral opposed to the idea -- not to keep the stuff to myself, but to not
stance. IMHO, of course. hinder the platform-neutral stance. IMHO, of course.</P>
<P>Of course, there are many projects that DO include all the files <P>Of course, there are many projects that DO include all the files
necessary to build RPMs from their Official Tarball (TM). 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 <P>2001-05-07</P>
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 <P>If you just do basic "cvs checkout", "cvs update", "cvs commit",
are interested in getting at. To do this, look at some long-lived file, then you'll always be dealing with the HEAD version of the files in
say the top-level HISTORY file, with "cvs status -v" to see what the CVS. That's what you want for development, but if you need to patch
branch names are. (Thanks to Ian Lance Taylor for pointing out that past stable releases then you have to be able to access and update
this is the easiest way to do it.) Typical branch names are: 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> <P>2001-06-22</P>
&gt; If someone was interested in joining the development team, where would
<BR>
&gt; they...
<BR>
&gt; - Find a description of the open source development process used by the
<BR>
&gt; PostgreSQL team.
<BR>
<P>Read HACKERS for six months (or a full release cycle, whichever is longer). <P>&gt; If someone was interested in joining the development team,
Really. HACKERS _is_the process. The process is not well documented (AFAIK where would<BR>
-- it may be somewhere that I am not aware of) -- and it changes continually. &gt; they...<BR>
&gt; - Find a description of the open source development process
used by the<BR>
&gt; PostgreSQL team.<BR>
</P>
<P> <P>Read HACKERS for six months (or a full release cycle, whichever
&gt; - Find the development environment (OS, system, compilers, etc) is longer). Really. HACKERS _is_the process. The process is not
<BR> well documented (AFAIK -- it may be somewhere that I am not aware
&gt; required to develop code. of) -- and it changes continually.</P>
<BR>
<P><a href="developers.postgresql.org">Developers Corner</a> on the website <P>&gt; - Find the development environment (OS, system, compilers,
has links to this information. The distribution tarball itself etc)<BR>
includes all the extra tools and documents that go beyond a good &gt; required to develop code.<BR>
Unix-like development environment. In general, a modern unix with a </P>
modern gcc, GNU make or equivalent, autoconf (of a particular version),
and good working knowledge of those tools are required.
<P> <P><A href="developers.postgresql.org">Developers Corner</A> on the
&gt; - Find an area or two that needs some support. website has links to this information. The distribution tarball
<BR> 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.</P>
<P>The TODO list. <P>&gt; - Find an area or two that needs some support.<BR>
</P>
<P>You've made the first step, by finding and subscribing to HACKERS. Once you <P>The TODO list.</P>
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.
<P>Discussion on the patch typically happens here. If the patch adds a major <P>You've made the first step, by finding and subscribing to
feature, it would be a good idea to talk about it first on the HACKERS list, HACKERS. Once you find an area to look at in the TODO, and have
in order to increase the chances of it being accepted, as well as toavoid read the documentation on the internals, etc, then you check out a
duplication of effort. Note that experienced developers with a proven track current CVS,write what you are going to write (keeping your CVS
record usually get the big jobs -- for more than one reason. Also note that checkout up to date in the process), and make up a patch (as a
PostgreSQL is highly portable -- nonportable code will likely be dismissed context diff only) and send to the PATCHES list, prefereably.</P>
out of hand.
<P>Once your contributions get accepted, things move from there. Typically, you <P>Discussion on the patch typically happens here. If the patch
would be added as a developer on the list on the website when one of the adds a major feature, it would be a good idea to talk about it
other developers recommends it. Membership on the steering committee is by first on the HACKERS list, in order to increase the chances of it
invitation only, by the other steering committee members, from what I have being accepted, as well as toavoid duplication of effort. Note that
gathered watching froma distance. 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.</P>
<P>I make these statements from having watched the process for over two years. <P>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.</P>
<P>To see a good example of how one goes about this, search the archives for the <P>I make these statements from having watched the process for over
name 'Tom Lane' and see what his first post consisted of, and where he took two years.</P>
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 <P>To see a good example of how one goes about this, search the
few days to read after him. And pay special attention to both the sheer archives for the name 'Tom Lane' and see what his first post
quantity as well as the painstaking quality of his work. Both are in high consisted of, and where he took things. In particular, note that
demand. 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.</P>
</BODY> </BODY>
</HTML> </HTML>