From 2c0ce5ff87c5a5295ca7a5ac9edcb781689312a8 Mon Sep 17 00:00:00 2001 From: Drew Guarnera Date: Wed, 16 Oct 2019 11:54:06 -0400 Subject: [PATCH 1/3] Update contribution documentation with better PR policies --- CONTRIB.md | 17 +++++++++++++++-- 1 file changed, 15 insertions(+), 2 deletions(-) diff --git a/CONTRIB.md b/CONTRIB.md index c1d8b28..0aa9417 100644 --- a/CONTRIB.md +++ b/CONTRIB.md @@ -16,11 +16,24 @@ * Addition of any 3rd party libraries (other than support for trackers) must be requested in a GitHub issue complete with links to the library and explanation of its need/value for the project. ### Branching -* The master branch is used for the most recent and tested stable release. No commits are to be added to the master branch by anyone other than a release manager. +* The master branch is used for the most recent and tested stable release. +* **No commits are to be added to the master branch by anyone other than a release manager.** +* Merging temporary fix/feature branches into will be done via pull request and by a release manager. * The develop branch contains tested features to be included in the next release. * If you are an internal member of the project and collaborating on features, please make your changes in a branch named issue##-keyword, where ## represents the issue number and a keyword or short phrase is provided to easily identify the branch. +### Patch Fixes for Existing Releases +* If a bug fix is required for an existing release, changes must be made based on the appropriate release tag. +* Fixes will be done in a temporary branch, and a pull request will be submitted to merge those changes with master (and development if appropriate). +* Patched releases will be packaged at the discression of the development team and PI(s). +* The subsequent patched release **must** have a release tag generated at the time of release (freezing the state). + ### Pull Requests -* NO CODE IS TO BE MERGED INTO MASTER OR DEVELOP WITHOUT A PULL REQUEST FOR CODE REVIEW. +* **NO CODE IS TO BE MERGED INTO STAGING BRANCHES (MASTER, DEVELOPMENT, ETC) WITHOUT A PULL REQUEST FOR CODE REVIEW.** +* Pull requests will be used to migrate fixes and features into staging branches. +* Pull requests **must** be based on an existing issue on GitHub. +* A pull request must be reviewed by at least one development team member other than the original author (with two being preferrable). +* Pull requests must outline what testing was done by the author(s) prior to the pull request, and briefly describe the fix/feature. +* Pull request reviews must contain testing procedures used by the reviewer(s) or indicate that procedures were repeated as outlined by the original pull request author(s) or other reviewer(s). * Ensure that you periodically update branches with code changes from your branch base (master/develop/etc) to ensure that regressions and merge conflicts are resolved before pull requests are submitted. * If you are having difficulties with a merge conflict or are uncomfortable making a pull request, please reach out to another member of the development group via an issue comment or Discord. From 6becd16cde27fcfa965c97d16d6c79fb5fe946e1 Mon Sep 17 00:00:00 2001 From: Drew Guarnera Date: Fri, 18 Oct 2019 11:44:20 -0400 Subject: [PATCH 2/3] Address pull request comment regarding QT --- CONTRIB.md | 1 - 1 file changed, 1 deletion(-) diff --git a/CONTRIB.md b/CONTRIB.md index 0aa9417..50d07ef 100644 --- a/CONTRIB.md +++ b/CONTRIB.md @@ -1,7 +1,6 @@ ### Coding Standards * Configure editor so indents are four spaces (Should be the default in Visual Studio 2017). * All source and WPF filenames will be Pascal Case (example: MainClass.cs). -* When possible If no standard library functionality exists, then use Qt. * Naming Styles: * We are primarily following these (guidelines)[https://docs.microsoft.com/en-us/dotnet/standard/design-guidelines/capitalization-conventions] from Microsoft with the exception of local variables * Class names, members, and functions will be Pascal Case From 48eefb0b73418eb98bacd8e715576ef64a7f60db Mon Sep 17 00:00:00 2001 From: Drew Guarnera Date: Fri, 18 Oct 2019 11:45:12 -0400 Subject: [PATCH 3/3] Add patching for previous release --- CONTRIB.md | 13 ++++++++----- 1 file changed, 8 insertions(+), 5 deletions(-) diff --git a/CONTRIB.md b/CONTRIB.md index 50d07ef..7c0bf6d 100644 --- a/CONTRIB.md +++ b/CONTRIB.md @@ -1,13 +1,12 @@ ### Coding Standards -* Configure editor so indents are four spaces (Should be the default in Visual Studio 2017). +* Configure editor so indents are four spaces (Should be the default in Visual Studio). * All source and WPF filenames will be Pascal Case (example: MainClass.cs). * Naming Styles: - * We are primarily following these (guidelines)[https://docs.microsoft.com/en-us/dotnet/standard/design-guidelines/capitalization-conventions] from Microsoft with the exception of local variables - * Class names, members, and functions will be Pascal Case + * We are primarily following these (guidelines)[https://docs.microsoft.com/en-us/dotnet/standard/design-guidelines/capitalization-conventions] from Microsoft with the exception of local variables. + * Class names, members, and functions will be Pascal Case. * Local variables and function parameters will be Camel Case (example: localVar). * Online examples from MS contradict the style guideline for local variables, but I feel this provides visual differentiation of scope for identifiers. * Constants will be in call caps. - * Do not use magic numbers. Instead, use named constants. ### Project Standards @@ -23,6 +22,9 @@ ### Patch Fixes for Existing Releases * If a bug fix is required for an existing release, changes must be made based on the appropriate release tag. + * This becomes important when patching a previous release and master has diverged (e.g. patching version 1.5 after 2.0 has been released). + * Hotfix/patch tags may be issued for patch fixes to previous releases. + * If master and the current tag are equivalent (same current release, master may be used as the base for changes). * Fixes will be done in a temporary branch, and a pull request will be submitted to merge those changes with master (and development if appropriate). * Patched releases will be packaged at the discression of the development team and PI(s). * The subsequent patched release **must** have a release tag generated at the time of release (freezing the state). @@ -32,7 +34,8 @@ * Pull requests will be used to migrate fixes and features into staging branches. * Pull requests **must** be based on an existing issue on GitHub. * A pull request must be reviewed by at least one development team member other than the original author (with two being preferrable). +* If no particular development team member is needed for review, using the @iTrace-Dev/itrace-developers in the pull request should notify all development team members of the pull request. * Pull requests must outline what testing was done by the author(s) prior to the pull request, and briefly describe the fix/feature. * Pull request reviews must contain testing procedures used by the reviewer(s) or indicate that procedures were repeated as outlined by the original pull request author(s) or other reviewer(s). * Ensure that you periodically update branches with code changes from your branch base (master/develop/etc) to ensure that regressions and merge conflicts are resolved before pull requests are submitted. -* If you are having difficulties with a merge conflict or are uncomfortable making a pull request, please reach out to another member of the development group via an issue comment or Discord. +* If you are having difficulties with a merge conflict or are uncomfortable making a pull request, please reach out to another member of the development group via a comment on the issue inquestions or Discord.