| 53 | | * Use meaningful descriptions for commit log entries. |
| 54 | | * Add a bug reference like "#1232" at the beginning or end of SVN commit log entries when committing changes related to a ticket in Trac. The '#' character enables Trac to create a hyperlink from the changeset to the mentioned ticket. |
| 55 | | * When new enhancements are added or breaking changes are made and completed the related ticket should have in '''keywords''' section of ticket the word '''history'''. This will better ensure it is not forgotten when preparing the news release and official doc release notes. |
| 56 | | * After committing changes related to a ticket in Trac, write the tree and revision in which it was fixed in the ticket description. Such as "Fixed in trunk r12345 and in branches/1.7 r12346". The 'r' character enables Trac to create a hyperlink from the ticket to the changeset. |
| 57 | | * Changes should not be committed in stable branches without a corresponding bug id. Any change worth pushing into the stable version is worth a bug entry. |
| 58 | | * Never commit new features to a stable branch without permission of the PSC or release manager. Normally only fixes should go into stable branches. |
| 59 | | * New features go in the main development trunk. |
| 60 | | * Only bug fixes should be committed to the code during pre-release code freeze, without permission from the PSC or release manager. |
| 61 | | * Significant changes to the main development version should be discussed on the postgis-dev list before you make them, and larger changes will require an RFC approved by the PSC. |
| 62 | | * Do not create new branches (except for spike branches) without the approval of the PSC. Release managers are assumed to have permission to create a branch. |
| 63 | | * spike branch (those in the spike/username area are to be used for experimentation or for major code refactoring that will destabilize the trunk. After such experimentation is deemed stable, this can then be merged into the trunk after approval from PSC members. |
| 64 | | * When committing new features or significant changes to existing source code, the committer should take reasonable measures to insure that the source code continues to build and work on the most commonly supported platforms (currently Linux and Windows), either by testing on those platforms directly, running Buildbot tests, or by getting help from other developers working on those platforms. If new files or library dependencies are added, then the configure.in, Makefile.in and related documentations should be kept up to date. |
| 65 | | * In the event of broken build (build bot fail notification), the person who broke the build must fix the break before working on anything else |
| | 53 | 1. Use meaningful descriptions for commit log entries. |
| | 54 | 2. Add a bug reference like "#1232" at the beginning or end of SVN commit log entries when committing changes related to a ticket in Trac. The '#' character enables Trac to create a hyperlink from the changeset to the mentioned ticket. |
| | 55 | 3. When new enhancements are added or breaking changes are made and completed the related ticket should have in '''keywords''' section of ticket the word '''history'''. This will better ensure it is not forgotten when preparing the news release and official doc release notes. |
| | 56 | 4. After committing changes related to a ticket in Trac, write the tree and revision in which it was fixed in the ticket description. Such as "Fixed in trunk r12345 and in branches/1.7 r12346". The 'r' character enables Trac to create a hyperlink from the ticket to the changeset. |
| | 57 | 5. Changes should not be committed in stable branches without a corresponding bug id. Any change worth pushing into the stable version is worth a bug entry. |
| | 58 | 6. Never commit new features to a stable branch without permission of the PSC or release manager. Normally only fixes should go into stable branches. |
| | 59 | 7. New features go in the main development trunk. |
| | 60 | 8. Only bug fixes should be committed to the code during pre-release code freeze, without permission from the PSC or release manager. |
| | 61 | 9. Significant changes to the main development version should be discussed on the postgis-dev list before you make them, and larger changes will require an RFC approved by the PSC. |
| | 62 | 10. Do not create new branches (except for spike branches) without the approval of the PSC. Release managers are assumed to have permission to create a branch. |
| | 63 | 11. spike branch (those in the spike/username area are to be used for experimentation or for major code refactoring that will destabilize the trunk. After such experimentation is deemed stable, this can then be merged into the trunk after approval from PSC members. |
| | 64 | 12. When committing new features or significant changes to existing source code, the committer should take reasonable measures to insure that the source code continues to build and work on the most commonly supported platforms (currently Linux and Windows), either by testing on those platforms directly, running Buildbot tests, or by getting help from other developers working on those platforms. If new files or library dependencies are added, then the configure.in, Makefile.in and related documentations should be kept up to date. |
| | 65 | 13. In the event of broken build (build bot fail notification), the person who broke the build must fix the break before working on anything else |
