Difference between revisions of "Development"
(→How to contribute to the Pgpool-II project) |
(→How to contribute to the Pgpool-II project) |
||
| Line 6: | Line 6: | ||
* New feature proposals should be discussed on [https://www.pgpool.net/mailman/listinfo/pgpool-hackers mailing list | * New feature proposals should be discussed on [https://www.pgpool.net/mailman/listinfo/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 most important thing: why this is good for users (and developers). The proposal need not to be completed. Just throwing an idea 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). | ||
= Projects in progress = | = Projects in progress = | ||
Revision as of 06:33, 12 September 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.
- Source code is managed by a 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.
- New feature proposals should be discussed on [https://www.pgpool.net/mailman/listinfo/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 completed. Just throwing an idea 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).
