Difference between revisions of "Development"

From pgpool Wiki
Jump to: navigation, search
(How to contribute to the Pgpool-II project)
 
(4 intermediate revisions by one other user not shown)
Line 2: Line 2:
 
: Pgpool-II is an open source project and the contribution style follows the way [https://www.postgresql.org PostgreSQL] does except that we don't have CF application.
 
: Pgpool-II is an open source project and the contribution style follows the way [https://www.postgresql.org PostgreSQL] does except that we don't have CF application.
  
* Source code is managed by a [https://git.postgresql.org/gitweb/?p=pgpool2.git;a=summary git repository].
+
* Source code is managed by the [https://git.postgresql.org/gitweb/?p=pgpool2.git;a=summary git repository].
 
: We maintain 5-6 stable branches (see https://pgpool.net/mediawiki/index.php/EOL_information for more details). The under development branch is always the master branch. We don't add new features to stable branches. New features should be added to the master branch.
 
: We maintain 5-6 stable branches (see https://pgpool.net/mediawiki/index.php/EOL_information for more details). The under development branch is always the master branch. We don't add new features to stable branches. New features should be added to the master branch.
  
 
* New feature proposals should be discussed on the [https://www.pgpool.net/mailman/listinfo/pgpool-hackers pgpool-hackers mailing list]
 
* New feature proposals should be discussed on the [https://www.pgpool.net/mailman/listinfo/pgpool-hackers pgpool-hackers mailing list]
: The proposal should include reason, back ground, architecture design, and the most important thing: why this is good for users (and developers). The proposal need not to be completed. Just throwing an idea is welcome.
+
: The proposal should include reason, back ground, architecture design, and the most important thing: why this is good for users (and developers). The proposal need not to be completed. Just throwing an idea to start a discussion is welcome.
 
: Actual code should be proposed as a patch to the master branch. A patch does not need to be included in the first, or early discussions.
 
: Actual code should be proposed as a patch to the master branch. A patch does not need to be included in the first, or early discussions.
 
: The committable patch should include not only complete code, but documentation (SGML format) and possibly tests (under src/test).
 
: The committable patch should include not only complete code, but documentation (SGML format) and possibly tests (under src/test).
: Once the patch is verified committers, committer will commit/push the patch to the master branch.
+
: Once the patch is verified by committers, a committer will commit/push the patch to the master branch.
  
 
= Projects in progress =
 
= Projects in progress =
  
 
* [https://pgpool.net/mediawiki/index.php/Pgpool-II_4.2_development pgpool-II 4.2 development]
 
* [https://pgpool.net/mediawiki/index.php/Pgpool-II_4.2_development pgpool-II 4.2 development]
* [https://pgpool.net/mediawiki/index.php/Pgpool-II_4.1_development pgpool-II 4.1 development]
+
 
  
 
= Projects already done =
 
= Projects already done =
 +
 +
* [https://pgpool.net/mediawiki/index.php/Pgpool-II_4.1_development pgpool-II 4.1 development]
  
 
* [https://pgpool.net/mediawiki/index.php/Pgpool-II_4.0_development pgpool-II 4.0 development]
 
* [https://pgpool.net/mediawiki/index.php/Pgpool-II_4.0_development pgpool-II 4.0 development]

Latest revision as of 01:01, 27 November 2019

How to contribute to the Pgpool-II project

Pgpool-II is an open source project and the contribution style follows the way PostgreSQL does except that we don't have CF application.
We maintain 5-6 stable branches (see https://pgpool.net/mediawiki/index.php/EOL_information for more details). The under development branch is always the master branch. We don't add new features to stable branches. New features should be added to the master branch.
The proposal should include reason, back ground, architecture design, and the most important thing: why this is good for users (and developers). The proposal need not to be completed. Just throwing an idea to start a discussion is welcome.
Actual code should be proposed as a patch to the master branch. A patch does not need to be included in the first, or early discussions.
The committable patch should include not only complete code, but documentation (SGML format) and possibly tests (under src/test).
Once the patch is verified by committers, a committer will commit/push the patch to the master branch.

Projects in progress


Projects already done