Context Navigation

Changes between Version 64 and Version 65 of DevWikiComitGuidelines

Timestamp:: Oct 12, 2017, 10:09:50 PM (7 years ago)
Author:: robe
Comment:: —

Legend:

: Unmodified
: Added
: Removed
: Modified

DevWikiComitGuidelines

-              v64
+              v65
 ||Version:|| 1.00000013
 ||Author:|| Regina Obe <lr at pcorp dot us>||
 ||Last Edited:|| 2012/05/04||
+||Last Edited:|| 2017/11/13||
 ||Status:|| Approved||
 …
 == Code and Documentation Conventions ==
   * C code should follow our designated [http://trac.osgeo.org/postgis/browser/trunk/STYLE Style Guidelines] to the best of your abilities
+  * All source code in SVN should be in Unix text format as opposed to DOS text mode.
+  * To accomplish Guidelines standards, we have implemented the use of editorconfig. Our repo as of version 2.4 now contains a .editorconfig file which editors configured with editorconfig support abide by.
+  * We ask all developers to work with an editor that has editorconfig support. Many editors have it or have it as plugins.
+  * All source code in SVN should be in Unix text format as opposed to DOS text mode with possibel exception of .bat files.
   * Each new/changed function should be documented in the official docs following our [wiki:DevWikiDocNewFeature Documentation Guidelines]
 == SVN Administrator ==
 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 file, and other SVN related management. That person will need login access on the SVN server of course.
+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.
 Initially Paul Ramsey will be the SVN Administrator.
 …
 . Use meaningful descriptions for commit log entries.
 . 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.
+. 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.
+. 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.
+. 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.
+. Never commit new features to a stable branch without permission of the PSC or release manager. Normally only fixes should go into stable branches.
+. New features go in the main development trunk.
+. Only bug fixes should be committed to the code during pre-release code freeze, without permission from the PSC or release manager.
+. 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.
+. 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.
+. 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.
+. 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.
+. 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
+. If you are given a patch from a community person, note their name in both the commit log entry and NEWS file.
+. 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.
+.  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.
+. When new enhancements are added or breaking changes are made and completed the related ticket should be added to the NEWS file.
+. 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.
+. Never commit new features to a stable branch without permission of the PSC or release manager. Normally only fixes should go into stable branches.
+. New features go in the main development trunk.
+. Only bug fixes should be committed to the code during pre-release code freeze, without permission from the PSC or release manager.
+. 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.
+. 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.
+. 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.
+. 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.
+. 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.
 == Committer Tracking ==
 …
     * A brief indication of areas of responsibility.
     * The name of key developers and their area of responsibility should also be  prominently shown in latest release of manual in the doc/introduction.xml file.
       This will be the responsibility of the documentation lead to ensure.
+      This will be the responsibility of the documentation lead (currently Regina Obe) to ensure.
 == Relationship with other Projects ==
 …
     * Make sure the contributor (and possibly employer) is aware of the contribution terms.
     * Code coming from a source other than the contributor (such as adapted from another project) should be clearly marked as to the original source, copyright holders, license terms and so forth. This information can be in the file headers, but should also be added to the project licensing file if not exactly matching normal project licensing.
     * Existing copyright headers and license text should never be stripped from a file. If a copyright holder wishes to give up copyright they must do so in writing to the foundation before copyright messages are removed. If license terms are changed it has to be by agreement (written in email is ok) of the copyright holders.
+    * Existing copyright headers and license text should never be stripped from a file. If a copyright holder wishes to give up copyright they must do so in writing to the OSGeo foundation before copyright messages are removed. If license terms are changed it has to be by agreement (written in email is ok) of the copyright holders.
     * Code with licenses requiring credit, or disclosure to users should be added to /postgis/trunk/LICENSE.TXT.
     * When substantial contributions are added to a file (such as substantial patches) the author/contributor should be added to the list of copyright holders for the file.
     * If there is uncertainty about whether a change is proper to contribute to the code base, please seek more information from the project steering committee, or the foundation legal counsel.
     * New contributors and company contributors should be added to the credits in doc/introduction.xml of the latest release of the PostGIS manual.
     * It is the responsibility of the document lead to insure when new enhancements are added or breaking changes are made, these are noted in the trunk/NEWS or relevant branch/NEWS as soon as conveniently possible. The note should include the trac # (unless a major feature with many tickets) and contributors to the feature/change.
+    * It is the responsibility of the document lead to ensure when new enhancements are added or breaking changes are made, these are noted in the trunk/NEWS or relevant branch/NEWS as soon as conveniently possible. The note should include the trac # (unless a major feature with many tickets) and contributors to the feature/change.
 == Bootstrapping ==
 …
     * Kevin Neufeld
     * Regina Obe  (P) Documentation Lead
     * Bborie Park
+    * Bborie Park (P)
     * Pierre Racine
     * Paul Ramsey (P) SVN Administrator