Changes between Version 74 and Version 75 of DevWikiComitGuidelines


Ignore:
Timestamp:
10/27/19 17:35:17 (5 years ago)
Author:
robe
Comment:

--

Legend:

Unmodified
Added
Removed
Modified

  • DevWikiComitGuidelines

    v74 v75  
    11= RFC-5: PostGIS Committer Guidelines =
    22
    3 ||Version:|| 1.00000014
     3||Version:|| 2.0
    44||Author:|| Regina Obe <lr at pcorp dot us>||
    5 ||Last Edited:|| 2017/10/16||
    6 ||Status:|| Approved||
     5||Last Edited:|| 2019/10/27||
     6||Status:|| Draft||
    77
    88== Changes to this file ==
    … …  
    2626
    2727== Code and Documentation Conventions ==
    28   * C code should follow our designated [http://trac.osgeo.org/postgis/browser/trunk/STYLE Style Guidelines] to the best of your abilities
     28  * C code should follow our designated [https://trac.osgeo.org/postgis/browser/git/STYLE Style Guidelines] to the best of your abilities
    2929  * To accomplish Guidelines standards, we have implemented the use of [http://editorconfig.org/ editorconfig]. Our repo as of version 2.4 now contains a .editorconfig file which editors configured with editorconfig support abide by.
    3030  * We ask all developers to work with an editor that has editorconfig support. Many editors have it or have it as plugins.
    31   * All source code in SVN should be in Unix text format as opposed to DOS text mode with possible exception of .bat files.
     31  * All source code in GIT should be in Unix text format as opposed to DOS text mode with possible exception of .bat files.
    3232  * Each new/changed function should be documented in the official docs following our [wiki:DevWikiDocNewFeature Documentation Guidelines]
    3333
    34 == SVN Administrator ==
     34== Repo Administrator ==
    3535
    36 One member of the Project Steering Committee will be designated as the SVN Administrator. That person will be responsible for giving SVN commit access to folks, updating the CREDITS  and authors.svn, authors.git file, and other SVN/GIT related management. That person will need login access on the SVN server of course.
     36One member of the Project Steering Committee will be designated as the Repo Administrator. That person will be responsible for giving commit access to folks, updating the CREDITS and authors.git file, and other repo related management.
    3737
    38 Paul Ramsey is currently designated as the SVN Administrator.
     38Paul Ramsey is currently designated as the Repo Administrator.
    3939
    40 **It is extremely critical that the new committer's user name be added to authors.svn and authors.git before their first commit otherwise the git replication will break.**
     40**TODO: Is this still true? It is extremely critical that the new committer's user name be added to authors.svn and authors.git before their first commit otherwise the git replication will break.**
    4141
    42 == SVN Commit and Bug, Feature Tracking Practices ==
     42== Commit and Bug, Feature Tracking Practices ==
    4343
    4444The following are considered good source commit and tracking practices for the PostGIS project.
    4545
    4646    1. Use meaningful descriptions for commit log entries.
    47     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.
    48     3. If you are given a patch from a community person, note their name in both the commit log entry and NEWS file.
    49     4. To close a ticket 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.
    50     5.  Similarly adding References #[xyz] will automatically put the commit log notes on the trac ticket. If you forget to add the notes to the commit log, edit the tract ticket 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 trunk r12345 and in branches/1.7 r12346". The 'r' character enables Trac to create a hyperlink from the ticket to the changeset.
     47    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.
     48       For small changes where there is no ticket and there is a pull request or patch, reference to these e.g. github/gitlab pull request link is sufficient
     49    3. 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.
     50    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.
     51    5. ** TODO: Not sure this is proper way to reference git** - Similarly adding References #[xyz] will automatically put the commit log notes on the trac ticket. If you forget to add the notes to the commit log, edit the trac ticket 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.
    5152    6. When new enhancements are added or breaking changes are made and completed the related ticket should be added to the NEWS file.
    5253    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.
    5354    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.
    54     9. New features go in the main development trunk.
     55    9. New features go in the main development master.
    5556    10. Only bug fixes should be committed to the code during pre-release code freeze, without permission from the PSC or release manager.
    5657    11. 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.
    57     12. 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.
    58     13. 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.  Using a git repo for experimentation instead of svn/spike is the preferred mode of experimentation these days.
     58    12. 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. spike branch (those in the spike/username area are to be used for experimentation or for major code refactoring that will destabilize the master  After such experimentation is deemed stable, this can then be merged into the master after approval from PSC members.
    5960    14. 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, Mac, 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.
    6061    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.