Difference between revisions of "Development"
(→How to contribute to the Pgpool-II project) |
|||
(8 intermediate revisions by 2 users 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 | + | * Source code is managed by the [https://git.postgresql.org/gitweb/?p=pgpool2.git;a=summary git repository]. |
− | : We maintain 5-6 stable branches. 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 [https://www.pgpool.net/mailman/listinfo/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 most important thing: why this is good for users (and developers). The proposal need not to be | + | : 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 in progress = | ||
+ | |||
+ | |||
+ | = Projects already done = | ||
* [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] | * [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] |
Revision as of 05:29, 2 December 2020
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.
- Source code is managed by the 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.
- New feature proposals should be discussed on the 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 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.