From: Mark Lobodzinski Date: Thu, 4 Jan 2018 23:12:41 +0000 (-0700) Subject: docs: Additional updates and corrections X-Git-Tag: sdk-1.0.68.0~95 X-Git-Url: http://review.tizen.org/git/?a=commitdiff_plain;h=34cd2e6c5369d70e3a64c9c7602ccbef8d543c6a;p=platform%2Fupstream%2FVulkan-LoaderAndValidationLayers.git docs: Additional updates and corrections Change-Id: Id2ade62aa11fb013b405e8426fdf4f90a05a48a4 --- diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index 8eb329e..dbc0925 100644 --- a/CONTRIBUTING.md +++ b/CONTRIBUTING.md @@ -12,9 +12,13 @@ The Vulkan validation layers are one of the larger and more important components While there are often active and organized development efforts underway to improve their coverage, there are always opportunities for anyone to help by contributing additional validation layer checks and tests for these validation checks. -If you desire to help in this area, please examine the -[issues list](https://github.com/KhronosGroup/Vulkan-LoaderAndValidationLayers/issues) -in this repository and look for any issues that are of interest to you. + +There are a couple of methods to identify areas of need: +* Examine the [issues list](https://github.com/KhronosGroup/Vulkan-LoaderAndValidationLayers/issues) +in this repository and look for issues that are of interest +* Alternatively, examine the [vk_validation_error_database.txt](layers/vk_validation_error_database.txt) file -- unimplemented validation checks are marked +with an 'N' in the 'check_implemented' column and each of these needs coverage in the validation layers. + Of course, if you have your own work in mind, please open an issue to describe it and assign it to yourself. Finally, please feel free to contact any of the developers that are actively contributing should you wish to coordinate further. @@ -28,7 +32,7 @@ Repository Issue labels: development that would have been directly useful, and are high priority. * _Enhancement_: These issues refer to ideas for extending or improving the loader, demos, or validation layers. -It is the mainainers goal for all issues to be assigned within one business day of their submission. If you choose +It is the maintainers goal for all issues to be assigned within one business day of their submission. If you choose to work on an issue that is assigned, simply coordinate with the current assignee. ### **How to Submit Fixes** @@ -38,7 +42,7 @@ to work on an issue that is assigned, simply coordinate with the current assigne * Use the existing GitHub forking and pull request process. This will involve [forking the repository](https://help.github.com/articles/fork-a-repo/), creating a branch with your commits, and then [submitting a pull request](https://help.github.com/articles/using-pull-requests/). -* Please read and adhere to the style and process [guidelines](#coding conventions and formatting) enumerated below. +* Please read and adhere to the style and process [guidelines ](#coding-conventions-and-formatting) enumerated below. * Please base your fixes on the master branch. SDK branches are generally not updated except for critical fixes needed to repair an SDK release. @@ -99,7 +103,7 @@ that to be accepted into the repository, the pull request must [pass all tests]( or you can run `run_all_tests.ps1` from a PowerShell window * Note that some tests may fail with known issues or driver-specific problems. - The idea here is that your changes shouldn't change the test results, unless that was the intent of your changes. + The idea here is that your changes should not change the test results, unless that was the intent of your changes. * Run tests that explicitly exercise your changes. * Feel free to subject your code changes to other tests as well! @@ -118,10 +122,9 @@ contains checks that require some amount of application state to carry out. In c checks that require (mostly) no state at all. Please inquire if you are unsure of the location for your contribution. The other layers (threading, object_tracker, unique_objects) are more special-purpose and are mostly code-generated from the specification. - ### **Contributor License Agreement (CLA)** -You'll be prompted with a one-time "click-through" CLA dialog as part of submitting your pull request +You will be prompted with a one-time "click-through" CLA dialog as part of submitting your pull request or other contribution to GitHub. ### **License and Copyrights** diff --git a/GOVERNANCE.md b/GOVERNANCE.md index 4b2e438..ac4b7c9 100644 --- a/GOVERNANCE.md +++ b/GOVERNANCE.md @@ -16,17 +16,18 @@ interpretations may require consulting with the Khronos Vulkan Workgroup for res - Google and LunarG collaboration: - Google: Monitor for Android - LunarG: Monitor for desktop (Windows and Linux) - - Continuous Integration: Internal HW test farms monitor various hardware/software platforms + - Continuous Integration: HW test farms operated by Google and LunarG monitor various hardware/software platforms * Repo Quality - Repo remains in healthy state with all tests passing and good-quality, consistent codebase - - Continuous Integration: Along with Github, internal test farms perform pre-commit cloud testing on pull-requests + - Continuous Integration: Along with Github, HW test farms operated by Google and LunarG perform pre-commit cloud testing +on pull-requests # **Roles and Definitions** * Contributor, Commenter, User - - Submitting contributions, issues, or users of the repository + - Submitting contributions, creating issues, or using the contents of the repository * Approver - Experienced project members who have made significant technical contributions - - Write control: Approve pull/merge requests (verify submissions vs. accepance criteria) + - Write control: Approve pull/merge requests (verify submissions vs. acceptance criteria) * Technical Project Leads - Lead the project in terms of versioning, quality assurance, and overarching objectives - Monitor github issues and drive timely resolution