mirror of
				https://github.com/postgres/postgres.git
				synced 2025-11-03 09:13:20 +03:00 
			
		
		
		
	Update text file.
This commit is contained in:
		
							
								
								
									
										61
									
								
								doc/FAQ_DEV
									
									
									
									
									
								
							
							
						
						
									
										61
									
								
								doc/FAQ_DEV
									
									
									
									
									
								
							@@ -1,7 +1,7 @@
 | 
				
			|||||||
 | 
					
 | 
				
			||||||
          Developer's Frequently Asked Questions (FAQ) for PostgreSQL
 | 
					          Developer's Frequently Asked Questions (FAQ) for PostgreSQL
 | 
				
			||||||
                                       
 | 
					                                       
 | 
				
			||||||
   Last updated: Sat Dec 24 14:29:33 EST 2005
 | 
					   Last updated: Wed Mar 1 17:24:48 EST 2006
 | 
				
			||||||
   
 | 
					   
 | 
				
			||||||
   Current maintainer: Bruce Momjian (pgman@candle.pha.pa.us)
 | 
					   Current maintainer: Bruce Momjian (pgman@candle.pha.pa.us)
 | 
				
			||||||
   
 | 
					   
 | 
				
			||||||
@@ -108,23 +108,52 @@ General Questions
 | 
				
			|||||||
   
 | 
					   
 | 
				
			||||||
  1.5) I've developed a patch, what next?
 | 
					  1.5) I've developed a patch, what next?
 | 
				
			||||||
  
 | 
					  
 | 
				
			||||||
   Generate the patch in contextual diff format. If you are unfamiliar
 | 
					   You will need to submit the patch to pgsql-patches@postgresql.org. It
 | 
				
			||||||
   with this, you might find the script src/tools/makediff/difforig
 | 
					   will be reviewed by other contributors to the project and will be
 | 
				
			||||||
   useful. Unified diffs are only preferrable if the file changes are
 | 
					   either accepted or sent back for further work. To help ensure your
 | 
				
			||||||
   single-line changes and do not rely on the surrounding lines.
 | 
					   patch is reviewed and committed in a timely fashion, please try to
 | 
				
			||||||
 | 
					   make sure your submission conforms to the following guidelines:
 | 
				
			||||||
 | 
					    1. Ensure that your patch is generated against the most recent
 | 
				
			||||||
 | 
					       version of the code, which for developers is CVS HEAD. For more on
 | 
				
			||||||
 | 
					       branches in PostgreSQL, see 1.15.
 | 
				
			||||||
 | 
					    2. Try to make your patch as readable as possible by following the
 | 
				
			||||||
 | 
					       project's code-layout conventions. This makes it easier for the
 | 
				
			||||||
 | 
					       reviewer, and there's no point in trying to layout things
 | 
				
			||||||
 | 
					       differently than pgindent. Also avoid unnecessary whitespace
 | 
				
			||||||
 | 
					       changes because they just distract the reviewer, and formatting
 | 
				
			||||||
 | 
					       changes will be removed by the next run of pgindent.
 | 
				
			||||||
 | 
					    3. The patch should be generated in contextual diff format (diff -c
 | 
				
			||||||
 | 
					       and should be applicable from the root directory. If you are
 | 
				
			||||||
 | 
					       unfamiliar with this, you might find the script
 | 
				
			||||||
 | 
					       src/tools/makediff/difforig useful. (Unified diffs are only
 | 
				
			||||||
 | 
					       preferable if the file changes are single-line changes and do not
 | 
				
			||||||
 | 
					       rely on surrounding lines.)
 | 
				
			||||||
 | 
					    4. PostgreSQL is licensed under a BSD license, so any submissions
 | 
				
			||||||
 | 
					       must conform to the BSD license to be included. If you use code
 | 
				
			||||||
 | 
					       that is available under some other license that is BSD compatible
 | 
				
			||||||
 | 
					       (eg. public domain) please note that code in your email submission
 | 
				
			||||||
 | 
					    5. Confirm that your changes can pass the regression tests. If your
 | 
				
			||||||
 | 
					       changes are port specific, please list the ports you have tested
 | 
				
			||||||
 | 
					       it on.
 | 
				
			||||||
 | 
					    6. Provide an implementation overview, preferably in code comments.
 | 
				
			||||||
 | 
					       Following the surrounding code commenting style is usually a good
 | 
				
			||||||
 | 
					       approach.
 | 
				
			||||||
 | 
					    7. New feature patches should also be accompanied by documentation
 | 
				
			||||||
 | 
					       patches. If you need help checking the SQL standard, see 1.16.
 | 
				
			||||||
 | 
					    8. If you are adding a new feature, confirm that it has been tested
 | 
				
			||||||
 | 
					       thoughly. Try to test the feature in all conceivable scenarios.
 | 
				
			||||||
 | 
					    9. If it is a performance patch, please provide confirming test
 | 
				
			||||||
 | 
					       results to show the benefit of your patch. It is OK to post
 | 
				
			||||||
 | 
					       patches without this information, though the patch will not be
 | 
				
			||||||
 | 
					       applied until somebody has tested the patch and found a
 | 
				
			||||||
 | 
					       significant performance improvement.
 | 
				
			||||||
       
 | 
					       
 | 
				
			||||||
   Ensure that your patch is generated against the most recent version of
 | 
					   Even if you pass all of the above, the patch might still be rejected
 | 
				
			||||||
   the code. If it is a patch adding new functionality, the most recent
 | 
					   for other reasons. Please be prepared to listen to comments and make
 | 
				
			||||||
   version is CVS HEAD; if it is a bug fix, this will be the most
 | 
					   modifications.
 | 
				
			||||||
   recently version of the branch which suffers from the bug (for more on
 | 
					 | 
				
			||||||
   branches in PostgreSQL, see 1.15).
 | 
					 | 
				
			||||||
   
 | 
					   
 | 
				
			||||||
   Finally, submit the patch to pgsql-patches@postgresql.org. It will be
 | 
					   You will be notified via email when the patch is applied, and your
 | 
				
			||||||
   reviewed by other contributors to the project and will be either
 | 
					   name will appear in the next version of the release notes.
 | 
				
			||||||
   accepted or sent back for further work. Also, please try to include
 | 
					 | 
				
			||||||
   documentation changes as part of the patch. If you can't do that, let
 | 
					 | 
				
			||||||
   us know and we will manually update the documentation when the patch
 | 
					 | 
				
			||||||
   is applied.
 | 
					 | 
				
			||||||
   
 | 
					   
 | 
				
			||||||
  1.6) Where can I learn more about the code?
 | 
					  1.6) Where can I learn more about the code?
 | 
				
			||||||
  
 | 
					  
 | 
				
			||||||
 
 | 
				
			|||||||
@@ -13,7 +13,7 @@
 | 
				
			|||||||
    <H1>Developer's Frequently Asked Questions (FAQ) for
 | 
					    <H1>Developer's Frequently Asked Questions (FAQ) for
 | 
				
			||||||
    PostgreSQL</H1>
 | 
					    PostgreSQL</H1>
 | 
				
			||||||
 | 
					
 | 
				
			||||||
    <P>Last updated: Sat Dec 24 14:29:33 EST 2005</P>
 | 
					    <P>Last updated: Wed Mar  1 17:24:48 EST 2006</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>
 | 
				
			||||||
 
 | 
				
			|||||||
		Reference in New Issue
	
	Block a user