| 44 | | 1. Use meaningful descriptions for commit log entries. |
| 45 | | 2. Add a bug reference like "#1232" at the beginning or end of 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. |
| 46 | | For small changes where there is no ticket and there is a pull request or patch, reference to these e.g. github/gitlab/gitea pull request link is sufficient |
| 47 | | 3. We allow contributions via patches (on trac or via mailing lists) or pull requests from our primary or [CodeMirrors git mirrors]. If you are given a patch or pull request from a community person, note their name in both the commit log entry and NEWS file. |
| 48 | | 4. To close a ticket or pull request you can add to your commit log Closes #[xyz] where xyx is the trac ticket, or Closes [link to pull request]. Our trac system has a hook to automatically close these on trac and our git mirrors. **DO NOT USE THE MERGE BUTTON** on pull requests. |
| 49 | | Do instead to merge changes into your local git and then push to our primary repo. This can be done using git merge or using the git patch link of the pull request (on all systems it's the git pull url with .patch or .diff at the end) and applying the patch. |
| 50 | | |
| 51 | | 5. Similarly adding References #[xyz] or References [link to pull request] will automatically put the commit log notes on the trac ticket/git pull request. If you forget to add the notes to the commit log, edit the trac ticket/git pull request and put the notes in - 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 master ..git hash and in branches/3.0 <githas>". The 'r' character enables Trac to create a hyperlink from the ticket to the changeset. |
| 52 | | 6. When new enhancements are added or breaking changes are made and completed the related ticket should be added to the NEWS file. |
| 53 | | 7. Changes should not be committed in stable branches without a corresponding bug id in NEWS. Any change worth pushing into the stable version is worth a bug entry. Bug fixes pushed to stable branches do not need to be noted in the development branch (except during alpha/beta/rc releases) because it is assumed the development branch includes all bug fixes of prior stable versions. |
| 54 | | 8. Never commit new features to a stable branch without permission of the PSC or release manager. Normally only fixes should go into stable branches. |
| 55 | | 9. New features go in the master branch. |
| 56 | | 10. Only bug fixes should be committed to the code during pre-release code freeze, without permission from the PSC or release manager. |
| 57 | | 11. Significant changes to the development version, in particular breaking backward-compatibility, should be discussed on the postgis-dev list before you make them, and larger changes will require an RFC approved by the PSC. |
| 58 | | 12. As a general rule, do not create new branches. Feature branches should be created in your own personal repo of choice. Release managers are assumed to have permission to create a branch. |
| 59 | | 13. 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, FreeBSD, Mac, and Windows), either by testing on those platforms directly, running CI 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. |
| 60 | | 15. After each commit, verify that all the build bots are happy on this page - https://trac.osgeo.org/postgis/ and if their unhappiness is caused by your commit, fix the issue before making any other changes. |
| | 44 | 1. Use meaningful descriptions for commit log entries. Format the git log to have a succint oneline description optionally followed by a detailed description after an empty line. Keep lines within 70 columns. Include trac ticket references in the detailed description. Ticket references will be signaled to trac so they can close tickets if "Closes #xxx" is found in the commit log or only result in comments if "References #xxx" is found. References to pull requests are better encoded as full links. |
| | 45 | 2. We allow contributions via patches (on trac or via mailing lists) or pull requests from our primary or [CodeMirrors git mirrors]. If you are given a patch or pull request from a community person, make sure to keep their names in the commit log (`git commit --author "Name Surname <email>"`) and NEWS file. DO NOT USE the `MERGE` button on [CodeMirrors git mirrors] as mirrors will be overridden and the merged commit will be discarded; merge manually to official repo instead. |
| | 46 | 3. We use https://trac.osgeo.org/postgis for planning so make sure pending changes have tickets there so they are not overlooked when cutting releases. If you forget to add trac ticket references in a commit log, edit the trac ticket and put the notes in, such as "Fixed in master ..git hash and in branches/3.0 <githas>". The 'r' character enables Trac to create a hyperlink from the ticket to the changeset. |
| | 47 | 4. Make sure the NEWS file is updated in master branch for new features/breaking changes and in all the stable branches for bugfixes. |
| | 48 | 5. Never commit new features to a stable branch without permission of the PSC or release manager. Normally only fixes should go into stable branches. |
| | 49 | 6. New features go in the master branch. |
| | 50 | 7. Only bug fixes should be committed to the master branch during pre-release code freeze, without permission from the PSC or release manager. |
| | 51 | 8. Significant changes to the master branch, in particular breaking backward-compatibility, should be discussed on the postgis-dev list before you make them, and larger changes will require an RFC approved by the PSC. |
| | 52 | 9. As a general rule, do not create new branches in the official repository. An exception to this rule is for when you want all CI bots to test your changes before pushing them to the target branch, in which case prefix your branch with a `test/` string. |
| | 53 | 10. 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, FreeBSD, Mac, and Windows), either by testing on those platforms directly, running CI 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. |
| | 54 | 11. After each commit, verify that all the build bots are happy on this page - https://trac.osgeo.org/postgis/ and if their unhappiness is caused by your commit, fix the issue before making any other changes. |
