If someone was interested in joining the development team, where would
they...

-  Find a description of the open source development process used by the
PostgreSQL team.

-  Find the development environment (OS, system, compilers, etc)
required to develop code.

-  Find an area or two that needs some support.


Thanks

Fri, 22 Jun 2001 11:55:46 -0400
"P. Dwayne Miller" <dmiller@espgroup.net>
Joining the team
I can't speak for the PostgreSQL team (well, is there such a thing?), but
in general, it doesn't quite work this way.

You usually start out as a user, find out the development environment,
etc, etc, use it for your project, then you find that there are few things
about a project that really make you itch. Then you scratch that itch, and
hopefully send your patch to the team. :)

On Fri, 22 Jun 2001, P. Dwayne Miller wrote:

> If someone was interested in joining the development team, where would
> they...
> 
> -  Find a description of the open source development process used by the
> PostgreSQL team.
> 
> -  Find the development environment (OS, system, compilers, etc)
> required to develop code.
> 
> -  Find an area or two that needs some support.
> 
> 
> Thanks
> 
> ---------------------------(end of broadcast)---------------------------
> TIP 6: Have you searched our list archives?
> 
> http://www.postgresql.org/search.mpl
> 
> 


Fri, 22 Jun 2001 12:53:20 -0400 (EDT)
Alex Pilosov <alex@pilosoft.com>
Re: Joining the team
On Friday 22 June 2001 11:55, P. Dwayne Miller wrote:
> If someone was interested in joining the development team, where would
> they...
> -  Find a description of the open source development process used by the
> PostgreSQL team.

Read HACKERS for six months (or a full release cycle, whichever is longer).  
Really.  HACKERS _is_the process.  The process is not well documented (AFAIK 
-- it may be somewhere that I am not aware of) -- and it changes continually.

> -  Find the development environment (OS, system, compilers, etc)
> required to develop code.

Developers Corner on the website has links to this information.  The 
distribution tarball itself includes all the extra tools and documents that 
go beyond a good Unix-like development environment.  In general, a modern 
unix with a modern gcc, GNU make or equivalent, autoconf (of a particular 
version), and good working knowledge of those tools are required.

> -  Find an area or two that needs some support.

The TODO list.

You've made the first step, by finding and subscribing to HACKERS.  Once you 
find an area to look at in the TODO, and have read the documentation on the 
internals, etc, then you check out a current CVS,write what you are going to 
write (keeping your CVS checkout up to date in the process), and make up a 
patch (as a context diff only) and send to the PATCHES list, prefereably.  

Discussion on the patch typically happens here.  If the patch adds a major 
feature, it would be a good idea to talk about it first on the HACKERS list, 
in order to increase the chances of it being accepted, as well as toavoid 
duplication of effort.  Note that experienced developers with a proven track 
record usually get the big jobs -- for more than one reason.  Also note that 
PostgreSQL is highly portable -- nonportable code will likely be dismissed 
out of  hand. 

Once your contributions get accepted, things move from there. Typically, you 
would be added as a developer on the list on the website when one of the 
other developers recommends it.  Membership on the steering committee is by 
invitation only, by the other steering committee members, from what I have 
gathered watching froma distance.

I make these statements from having watched the process for over two years.

To see a good example of how one goes about this, search the archives for the 
name 'Tom Lane' and see what his first post consisted of, and where he took 
things.  In particular, note that this hasn't been _that_ long ago -- and his 
bugfixing and general deep knowledge with this codebase is legendary.  Take a 
few days to read after him.  And pay special attention to both the sheer 
quantity as well as the painstaking quality of his work.  Both are in high 
demand.

Hope that helps!
--
Lamar Owen
WGCR Internet Radio
1 Peter 4:11

Fri, 22 Jun 2001 12:59:03 -0400
Lamar Owen <lamar.owen@wgcr.org>
Re: Joining the team
Alex Pilosov <alex@pilosoft.com> writes:
> You usually start out as a user, find out the development environment,
> etc, etc, use it for your project, then you find that there are few things
> about a project that really make you itch. Then you scratch that itch, and
> hopefully send your patch to the team. :)

Right.  Another comment is that there is no "required development
environment".  Ideally Postgres should run on pretty nearly any Unix-ish
operating system and pretty nearly any ANSI-C-ish compiler and C
library.  So use whatever floats your boat.  If things don't work
nicely, then you've got your first project: port to your preferred
platform.  I know one of the first things I had to do when I started
using Postgres was clean up some problems with its portability to HPUX.

			regards, tom lane

Fri, 22 Jun 2001 13:21:20 -0400
Tom Lane <tgl@sss.pgh.pa.us>
Re: Joining the team 

I have added this to the developer's FAQ.

---------------------------------------------------------------------------

> On Friday 22 June 2001 11:55, P. Dwayne Miller wrote:
> > If someone was interested in joining the development team, where would
> > they...
> > -  Find a description of the open source development process used by the
> > PostgreSQL team.
> 
> Read HACKERS for six months (or a full release cycle, whichever is longer).  
> Really.  HACKERS _is_the process.  The process is not well documented (AFAIK 
> -- it may be somewhere that I am not aware of) -- and it changes continually.
> 
> > -  Find the development environment (OS, system, compilers, etc)
> > required to develop code.
> 
> Developers Corner on the website has links to this information.  The 
> distribution tarball itself includes all the extra tools and documents that 
> go beyond a good Unix-like development environment.  In general, a modern 
> unix with a modern gcc, GNU make or equivalent, autoconf (of a particular 
> version), and good working knowledge of those tools are required.
> 
> > -  Find an area or two that needs some support.
> 
> The TODO list.
> 
> You've made the first step, by finding and subscribing to HACKERS.  Once you 
> find an area to look at in the TODO, and have read the documentation on the 
> internals, etc, then you check out a current CVS,write what you are going to 
> write (keeping your CVS checkout up to date in the process), and make up a 
> patch (as a context diff only) and send to the PATCHES list, prefereably.  
> 
> Discussion on the patch typically happens here.  If the patch adds a major 
> feature, it would be a good idea to talk about it first on the HACKERS list, 
> in order to increase the chances of it being accepted, as well as toavoid 
> duplication of effort.  Note that experienced developers with a proven track 
> record usually get the big jobs -- for more than one reason.  Also note that 
> PostgreSQL is highly portable -- nonportable code will likely be dismissed 
> out of  hand. 
> 
> Once your contributions get accepted, things move from there. Typically, you 
> would be added as a developer on the list on the website when one of the 
> other developers recommends it.  Membership on the steering committee is by 
> invitation only, by the other steering committee members, from what I have 
> gathered watching froma distance.
> 
> I make these statements from having watched the process for over two years.
> 
> To see a good example of how one goes about this, search the archives for the 
> name 'Tom Lane' and see what his first post consisted of, and where he took 
> things.  In particular, note that this hasn't been _that_ long ago -- and his 
> bugfixing and general deep knowledge with this codebase is legendary.  Take a 
> few days to read after him.  And pay special attention to both the sheer 
> quantity as well as the painstaking quality of his work.  Both are in high 
> demand.
> 
> Hope that helps!
> --
> Lamar Owen
> WGCR Internet Radio
> 1 Peter 4:11
> 
> ---------------------------(end of broadcast)---------------------------
> TIP 1: subscribe and unsubscribe commands go to majordomo@postgresql.org
> 

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

Tue, 27 Nov 2001 13:26:56 -0500 (EST)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: Joining the team
On Tuesday 27 November 2001 01:26 pm, Bruce Momjian wrote:
> I have added this to the developer's FAQ.
> > Developers Corner on the website has links to this information.  The
> > distribution tarball itself includes all the extra tools and documents

That would be developers.postgresql.org now, right?

> > Hope that helps!

Must've helped somebody.... :-)
-- 
Lamar Owen
WGCR Internet Radio
1 Peter 4:11

Tue, 27 Nov 2001 18:03:39 -0500
Lamar Owen <lamar.owen@wgcr.org>
Re: Joining the team
> On Tuesday 27 November 2001 01:26 pm, Bruce Momjian wrote:
> > I have added this to the developer's FAQ.
> > > Developers Corner on the website has links to this information.  The
> > > distribution tarball itself includes all the extra tools and documents
> 
> That would be developers.postgresql.org now, right?

Yes.  I added some http links to the text.


-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

Tue, 27 Nov 2001 18:40:47 -0500 (EST)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: Joining the team