diff --git a/CODE_OF_CONDUCT.md b/CODE_OF_CONDUCT.md index 5a9c0b7..247089d 100644 --- a/CODE_OF_CONDUCT.md +++ b/CODE_OF_CONDUCT.md @@ -1 +1,3 @@ -All participants agree to abide by LF Projects Code of Conduct (as defined in the [charter](tsc/charter.md)) available at https://lfprojects.org/policies/code-of-conduct/ \ No newline at end of file +# Code of Conduct + +The Code of Conduct of this repository if managed by the Code of Conduct of the overarching MoonRay project, defined in the [`OpenMoonRay/openmoonray` GitHub repository superproject](https://github.com/OpenMoonRay/openmoonray/blob/main/CODE_OF_CONDUCT.md). \ No newline at end of file diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index e5f235a..288ab82 100644 --- a/CONTRIBUTING.md +++ b/CONTRIBUTING.md @@ -1,108 +1,3 @@ -# Overview +# Contribution Policy -This project aims to be governed in a transparent, accessible way for the benefit of the community. All participation in this project is open and not bound to corporate affiliation. Participants are all bound to the [Code of Conduct](CODE_OF_CONDUCT.md). - -# Project roles - -## Contributor - -The contributor role is the starting role for anyone participating in the project and wishing to contribute code. - -### Process for becoming a contributor - -* Review the [coding standards](https://docs.openmoonray.org/developer-reference/coding-standards/) to ensure your contribution is in line with the project's coding and styling guidelines. -* Have a signed CLA on file ( see [below](#contributor-license-agreements) ) -* Have your submission approved by the [committer(s)](#committer) and merged into the codebase. - -#### License - -MoonRay is licensed under the [Apache, version 2.0](LICENSE.md) -license. Contributions to MoonRay should abide by that standard -license. - -#### Contributor License Agreements - -Developers who wish to contribute code to be considered for inclusion in MoonRay must first complete -a **Contributor License Agreement**, and email it to MoonRay@dreamworks.com and be sure to include -your GitHub username(s). - -* If you are an individual writing the code on your own time and - you're SURE you are the sole owner of any intellectual property you - contribute, you can [sign the CLA as an individual contributor](https://github.com/dreamworksanimation/openmoonray/blob/main/tsc/icla.md). - -* If you are writing the code as part of your job, or if there is any - possibility that your employers might think they own any - intellectual property you create, then you should use the [Corporate - Contributor Licence - Agreement](https://github.com/dreamworksanimation/openmoonray/blob/main/tsc/ccla.md). - -The MoonRay CLAs are in the [OpenMoonRay repo](https://github.com/dreamworksanimation/openmoonray/tree/main/tsc). - -#### Commit Sign-Off - -Every commit must be signed off. That is, every commit log message -must include a “`Signed-off-by`” line (generated, for example, with -“`git commit --signoff`”), indicating that the committer wrote the -code and has the right to release it under the -[Apache License, version 2.0](LICENSE) -license. See [http://developercertificate.org](http://developercertificate.org/) for more information on this requirement. - -## Committer - -The committer role enables the participant to commit code directly to the repository, but also comes with the obligation to be a responsible leader in the community. - -### Process for becoming a committer - -* Show your experience with the codebase through contributions and engagement on the community channels. -* Request to become a committer. -* Have the majority of committers approve you becoming a committer. -* Your name and email is added to the [MAINTAINERS](MAINTAINERS.md) file for the project. - -### Committer responsibilities - -* Monitor email aliases. -* Monitor Forums (delayed response is perfectly acceptable). -* Triage GitHub issues and perform pull request reviews for other committers and the community. -* Make sure that ongoing PRs are moving forward at the right pace or close them. -* Remain an active contributor to the project in general and the code base in particular. - -### When does a committer lose committer status? - -If a committer is no longer interested or cannot perform the committer duties listed above, they -should volunteer to be moved to emeritus status. In extreme cases this can also occur by a vote of -the committers per the voting process below. - -## Technical Steering Committee (TSC) member - -The Technical Steering Committee (TSC) oversees the overall technical direction of MoonRay, as defined in the [charter](charter.md). - -TSC voting members consist of committers that have been nominated by the committers, with a supermajority of voting members required to have a committer elected to be a TSC voting member. TSC voting members term and succession is defined in the [charter](charter.md). - -All meetings of the TSC are open to participation by any member of the MoonRay community. Meeting times are listed in the [MoonRay technical community calendar](https://calendar.google.com/calendar/embed?src=c_0104aeaceaad2fdc2db4264d1b1211ed56c33cb51086cd5a2a8df324158d21c5%40group.calendar.google.com&ctz=America%2FLos_Angeles). - -## Current TSC members - -* Jon Lanz, Chair / DreamWorks -* Toshi Kato / DreamWorks -* Rob Wilson / DreamWorks - -# Release Process - -Project releases will occur on a scheduled basis as agreed to by the TSC. - -# Conflict resolution and voting - -In general, we prefer that technical issues and committer status/TSC membership are amicably worked out -between the persons involved. If a dispute cannot be decided independently, the TSC can be -called in to decide an issue. If the TSC themselves cannot decide an issue, the issue will -be resolved by voting. The voting process is a simple majority in which each TSC receives one vote. - -# Communication - -This project, just like all of open source, is a global community. In addition to the [Code of Conduct](CODE_OF_CONDUCT.md), this project will: - -* Keep all communication on open channels ( mailing list, forums, chat ). -* Be respectful of time and language differences between community members ( such as scheduling meetings, email/issue responsiveness, etc ). -* Ensure tools are able to be used by community members regardless of their region. - -If you have concerns about communication challenges for this project, please contact the [TSC](mailto:MoonRay_TSC@dreamworks.com). +The Contribution Policy of this repository if managed by the Contribution Policy of the overarching MoonRay project, defined in the [`OpenMoonRay/openmoonray` GitHub repository superproject](https://github.com/OpenMoonRay/openmoonray/blob/main/CONTRIBUTING.md). \ No newline at end of file diff --git a/MAINTAINERS.md b/MAINTAINERS.md deleted file mode 100644 index 0d53828..0000000 --- a/MAINTAINERS.md +++ /dev/null @@ -1,12 +0,0 @@ - - - -# MoonRay Committers - -The current MoonRay maintainers are: - - -| Name | Email | -| --------------------------------| ---------------------------------- | -| DreamWorks MoonRay Contributors | MoonRayContributors@dreamworks.com | - diff --git a/README.md b/README.md index 0239990..3edcf2d 100644 --- a/README.md +++ b/README.md @@ -1,4 +1,7 @@ -# RATS CTest suite +# rats - part of the [MoonRay](https://github.com/OpenMoonRay/openmoonray) project +Policies concerning [Governance](https://github.com/OpenMoonRay/openmoonray/blob/main/GOVERNANCE.md), [Code of Conduct](https://github.com/OpenMoonRay/openmoonray/blob/main/CODE_OF_CONDUCT.md), and [Contribution](https://github.com/OpenMoonRay/openmoonray/blob/main/CONTRIBUTING.md) are available in the overarching MoonRay project, defined in the [`OpenMoonRay/openmoonray` GitHub repository superproject](https://github.com/OpenMoonRay/openmoonray). + +## RATS CTest suite The purpose of the Render Acceptance Test Suite (RATS) is to catch visual regressions caused by changes to the codebase that may be intentional or unintentional before those changes are deployed into a production environment. It works by comparing canonical images rendered with a previously sanctioned version of the renderer to images rendered with a developmental version (i.e. built from your bug/feature branch). RATS is built on the [CTest](https://cmake.org/cmake/help/book/mastering-cmake/chapter/Testing%20With%20CMake%20and%20CTest.html) framework. @@ -23,7 +26,7 @@ ctest -L 'render|diff' -j $(nproc) The examples above are not complete. See the "RATS runtime environment" section below for more information on running the tests. -## RATS runtime environment +### RATS runtime environment You must run the RATS tests from the build directory, after sourcing the moonray runtime environment script (`setup.sh`). You must also specify the location of the canonical images via the RATS_CANONICAL_DIR environment variable. @@ -35,7 +38,7 @@ export RATS_CANONICAL_DIR=/path/to/my/rats_canonicals ctest -L 'render|diff' ``` -## Test labels +### Test labels To facilitate running the tests in subsets we leverage the [LABELS](https://cmake.org/cmake/help/latest/prop_test/LABELS.html) property of CTest tests as well as a naming convention (see below). The `-L` and `-LE` `ctest` command-line arguments allow for selecting which tests are included or excluded by performing regular expression matching against each test's _labels_. @@ -47,7 +50,7 @@ The tests in the RATS suite are named and labeled according to their purpose. The tests with the _render_ and _diff_ labels can be run together, e.g. `ctest -L 'render|diff'`. An explicit dependency ensures that the _render_ test is executed prior to the associated _diff_ test. -### _update_ +#### _update_ The tests with the _update_ label perform the following steps: - the test scene is rendered 25 times, resulting in 25 sets of candidate images - each of these images is compared with the other images via per-pixel absolute difference @@ -66,33 +69,33 @@ It is likely that each class of machine that is intended to run the RATS suite w These tests are considered passing if they successfully execute the steps outlined above. -### _render_ +#### _render_ The tests with the _render_ label perform the following steps: - the test scene is rendered once, with the resulting test images written to the build directory for that test. These tests are considered passing if they successfully render the scene. -### _diff_ +#### _diff_ The tests with the _diff_ label are meant to be run with or just after the tests with the _render_ label, and perform the following steps: - the test images are compared with the associated canonical images using OpenImageIO's [idiff](https://openimageio.readthedocs.io/en/latest/idiff.html) tool with the difference thresholds found in the associated diff.json file. These tests are considered passing if the differences between the test images and the canonical images are within the thresholds specified in the diff.json file. -### _header_ +#### _header_ The tests with the _header_ label are meant to be run with or just after the tests with the _render_ label, and perform the following steps: - the metadata found in the test image headers is compared with that in the associated canonical image headers. These tests are considered passing if the metadata is considered the same. -## Test names +### Test names The tests are named using a convention of tokens separated by hyphens in the form `--`. - The first token is the RATS test stage and is one of ***update***|***render***|***diff***|***header***. - The second token is the MoonRay execution mode, abbreviated to 3 characters and is one of ***sca***|***vec***|***xpu*** for scalar, vector and xpu execution modes. - The third token is the name of the test, which by convention matches the relative directory structure of the test within the rats/tests/ directory. - For tests belonging to the _diff_ stage a fourth token is appended corresponding to the image filename being compared with its canonical counterpart, eg. ***-scene.exr***. -## Filtering which tests are run by name and label +### Filtering which tests are run by name and label This test naming/labeling convention allows for control over running certain groups of tests using the `-R`, `-E`, `-L` and `-LE` command-line arguments that `ctest` accepts. The regular expression syntax and overlapping behavior is poorly documented, but luckily ctest's `-N` command-line argument will print a list of the tests that match without actually executing the tests. @@ -122,19 +125,19 @@ ctest -L 'vector|xpu' -L 'render|diff' -R 'moonray/geometry' CTest has several other ways to choose which tests are run, such as by individual test numbers or by reading a list of tests from a file. See the CTest documentation for more info. -## The Contents of the RATS test suite -### Assets +### The Contents of the RATS test suite +#### Assets The assets/ directory uses [Git Large File Storage](https://git-lfs.com/) (LFS) and contains some simple assets that are used by the tests. * models/ : a few simple models in .usdc format * hdri/ : a few simple HDRI images in .exr format * textures/ : a few simple textures in .tx format -### Tests +#### Tests The tests are split into two directories based on the executable used to render the images, and contain the scene files and CMakeLists.txt scripts for building the tests. * tests/moonray * tests/hd_render (currently only contains a single test) -### The CMake scripts for generating the tests +#### The CMake scripts for generating the tests The RATS test suite is implemented on top of CTest and this directory contains the source. * cmake/ diff --git a/tsc/ccla.md b/tsc/ccla.md deleted file mode 100644 index 098ad2b..0000000 --- a/tsc/ccla.md +++ /dev/null @@ -1,56 +0,0 @@ -Corporate Contributor License Agreement ("Agreement") - -Thank you for your interest in the MoonRay (aka OpenMoonRay) Project (hereinafter "Project") -which has selected the Apache License, Version 2.0 (hereinafter "Apache 2.0 License") for its -inbound contributions. The terms You, Contributor and Contribution are used here as defined in -the Apache 2.0 License. - -The Project is required to have a Contributor License Agreement (CLA) on file that binds each -Contributor. - -You agree that all Contributions to the Project made by You or by Your designated employees -shall be licensed to the Project under the Apache 2.0 License, and that You agree to, and shall be -bound by, the terms of the Apache 2.0 License for all contributions made by You and Your -employees. Your initial list of designated employees who are authorized to make Contributions -shall be as set forth in Schedule A. You agree to identify Your initial CLA Manager below and -thereafter provide any updates to the identity of your CLA Manager or employees eligible to -make Contributions by providing updated lists to MoonRay@dreamworks.com. - -You certify that, for all Contributions to the Project made by You or by Your designated -employees: - - (a) The Contribution was created in whole or in part by You or Your designated -   employees and You have the right to submit it under the Apache 2.0 License; or - - (b) The Contribution is based upon previous work that, to the best of Your knowledge, is -   covered under an appropriate open source license and You have the right under that -   license to submit that work with modifications, whether created in whole or in part by -   You or Your designated employees, under the Apache 2.0 License; or - - (c) The Contribution was provided directly to You or Your designated employees by -   some other person who certified (a) or (b) and You or Your designated employees have -   not modified it. - -You acknowledge and agree that the Project and the Contribution are public and that a record of -the Contribution (including all personal information You or Your designated employees submit -with it, including Your or Your designated employees’ sign-off) is maintained indefinitely and -may be redistributed consistent with the Project or the Apache 2.0 License. - -Initial CLA Manager (Name and Email): ______________________________________ - -Company Name: ____________________________________________ - -Signature: _______________________________________________ - -Name: _______________________________________________ - -Title _______________________________________________ - -Date: _______________________________________________ - - -\**************************************************************************** -            **Schedule A** - - -\[Initial list of designated employees\] diff --git a/tsc/charter.md b/tsc/charter.md deleted file mode 100644 index 34d0d25..0000000 --- a/tsc/charter.md +++ /dev/null @@ -1,220 +0,0 @@ -**Technical Charter (the “Charter”) for MoonRay** - -**[ \_ ] [ \_ ], 2023** - - -This charter (the “Charter”) sets forth the responsibilities and procedures for technical contribution - to, and oversight of, the **MoonRay (aka OpenMoonRay)** project (the “Project”), - which has been established as **MoonRay** by DreamWorks Animation L.L.C. (“DreamWorks”). - All Contributors to the Project must comply with the terms of this Charter. - -**1. Mission and Scope of the Project** - - a. The mission of the Project is to continue maintenance and development of an -   open source project with the goals indicated in the “README” file within the -   Project’s code repository. - - b. The scope of the Project includes using existing MoonRay repositories to seed the -   Project, and software development under an OSI-approved open source license -   supporting the mission, including documentation, testing, integration and the -   creation of other artifacts that aid the development, deployment, operation or -   adoption of the open source software project. - -**2. Technical Steering Committee** - - a. The Technical Steering Committee (the “TSC”) will be responsible for all -   technical oversight of the open source Project. - - b. The TSC voting members shall be as set forth within the “CONTRIBUTING” file -   within the Project’s code repository. A voting member of the TSC may nominate -   a successor in the event that such voting member decides to leave the TSC, and -   the TSC, including the departing member, shall confirm or reject such nomination -   by a vote. In the event that the departing member’s nomination for successor is -   rejected by vote of the TSC, the departing member shall be entitled to continue -   nominating successors until one such successor is confirmed by vote of the TSC. -   If the departing member fails or is unable to nominate a successor, the TSC may -   nominate one on the departing member’s behalf. The TSC may also determine if -   and how additional voting members of the TSC are chosen, and any such -   approach will be documented in the CONTRIBUTING file, provided that such -   approach does not conflict with this Charter. Any meetings of the TSC are -   intended to be open to the public, except where there is a reasonable need for -   privacy, and can be conducted electronically, via teleconference, or in person. - - c. TSC projects generally will involve Contributors and Committers. The TSC may -   adopt or modify roles so long as the roles are documented in the -   CONTRIBUTING file. Unless otherwise documented: - -    i. Contributors include anyone in the technical community that contributes -       code, documentation, or other technical artifacts to the Project; - -    ii. Committers are Contributors who have earned the ability to modify -       (“commit”) source code, documentation or other technical artifacts in the -       Project’s repository; and - -    iii. A Contributor may become a Committer by a majority approval of -       the existing Committers or at the discretion of the TSC. A Committer may be -       removed by a majority approval of the other existing Committers, or at the -       the discretion of the TSC. - - d. Participation in the Project through becoming a Contributor and Committer is -   open to anyone so long as they abide by the terms of this Charter. - - e. The TSC may (1) establish workflow procedures for the submission, approval, -   and closure/archiving of projects, (2) set requirements for the promotion of -   Contributors to Committer status, as applicable, and (3) amend, adjust, refine -   and/or eliminate the roles of Contributors, and Committers, and create new roles, -   and publicly document any TSC roles, as it sees fit. - - f. The TSC may elect a TSC Chair, who will preside over meetings of the TSC and -   will serve until his or her resignation or replacement by the TSC. - - g. Responsibilities: The TSC will be responsible for all aspects of oversight relating -   to the Project, which may include: - -    i. coordinating the technical direction of the Project; - -    ii. approving project or system proposals (including, but not limited -       to, incubation, deprecation, and changes to a sub-project’s scope); - -    ii. organizing sub-projects and removing projects; - -    iv. creating sub-committees or working groups to focus on cross-project -       technical issues and requirements; - -    v. appointing representatives to work with other open source or open -       standards communities; - -    vi. establishing community norms, workflows, issuing releases, and security -       issue reporting policies; - -    vii. approving and implementing policies and processes for contributing (to be -       published in the CONTRIBUTING file) and coordinating with the Series -       Manager or its designee to resolve matters or concerns that may arise as -       set forth in Section 7 of this Charter; - -    viii. discussions, seeking consensus, and where necessary, voting on technical -       matters relating to the code base that affect multiple projects; - -    ix. coordinating any marketing, events, or communications regarding the -       Project; and - -    x. ensuring that the Project (x) is developed and maintained in a professional -       manner consistent with maintaining a cohesive community, while also -       maintaining the goodwill and esteem of [entity] and other partner -       organizations in the open source software community, and (y) respects the -       rights of all trademark owners, including any branding and trademark -       usage guidelines. - -**3. TSC Voting** - - a. Although the Project aims to operate as a consensus-based community, if any -   TSC decision requires a vote to move the Project forward, the voting members of -   the TSC will vote on a one vote per voting member basis. - - b. At least fifty percent of all voting members of the TSC must be present at a TSC -   meeting in order to establish a quorum. The TSC may continue to meet if a -   quorum is not met, but will be prevented from making any decisions at any such -   meeting. - - c. Except as provided in Section 7.c. and 8.a, decisions by vote at a meeting require -   a majority vote of those in attendance, provided a quorum is met. Decisions made -   by electronic vote without a meeting require a majority vote of all voting -   members of the TSC. - - d. In the event a vote cannot be resolved by the TSC, any voting member of the TSC -   may refer the matter to the Series Manager or its designee for assistance in -   reaching a resolution. - -**4. Compliance with Policies** - - a. The TSC may adopt a code of conduct (“CoC”) for the Project, which is subject to -   approval by DreamWorks. Contributors to the Project will comply with the CoC. - - b. When amending or adopting any policy applicable to the Project, the TSC will -   publish such policy, as to be amended or adopted, on its web site at least 30 days -   prior to such policy taking effect. - - c. All participants must allow open participation from any individual or organization -   meeting the requirements for contributing under this Charter and any policies -   adopted for all participants by the TSC, regardless of competitive interests. Put -   another way, the Project community must not seek to exclude any participant -   based on any criteria, requirement, or reason other than those that are reasonable -   and applied on a non-discriminatory basis to all participants in the Project -   community. - - d. The Project will operate in a transparent, open, collaborative, and ethical manner -   at all times. The output of all Project discussions, proposals, timelines, decisions, -   and status should be made open and easily visible to all. - - d. Any violations of the CoC or the requirements above should be reported to -   DreamWorks. - -**5. Project Assets** - - a. DreamWorks will hold title to all trade or service marks used by the Project -   (“Project Trademarks”), whether based on common law or registered rights. Any -   new Project Trademarks will be transferred and assigned to DreamWorks to hold -   on behalf of the Project. Any use of any Project Trademarks by participants in the -   Project will be in accordance with the license from DreamWorks and inure to the -   benefit of DreamWorks. - - b. The Project will develop and own all Project GitHub and social media accounts, -   and domain name registrations created by the Project community. - - -**6. Intellectual Property Policy** - - a. Participants acknowledge that the copyright in all new contributions will be -   retained by the copyright holder as independent works of authorship and that no -   contributor or copyright holder will be required to assign copyrights to any other -   party. - - b. Except as described in Section 6.c., all code contributions to the Project are -   subject to the following: - -    i. All new inbound code contributions to the Project must be made using an -       OSI-approved open source license specified for the Project within the -       “LICENSE” file within the Project’s code repository (the “Project -       License”). - -    ii. All new inbound code contributions must: - -      1. Be made pursuant to a binding Project Contribution License -         Agreement (the “CLA”) available on the Project’s web site; and - -      2. Be accompanied by a Developer Certificate of Origin -         (http://developercertificate.org) sign-off in the source code system -         that is submitted through a TSC-approved contribution process -         which will bind the authorized contributor and, if not self- -         employed, their employer to the applicable license; - -    iii. All outbound code will be made available under the Project License - -    iv. Documentation will be received and made available by the Project under -        the Creative Commons Attribution 4.0 International License (available at -        http://creativecommons.org/licenses/by/4.0/). - -    v. The TSC may seek to integrate and contribute back elements of the -        Project to other open source projects (“Upstream Projects”). In such cases, the -        contributed elements will conform to all license requirements of the -        Upstream Projects, including dependencies, leveraged by those elements. -        Upstream Project code contributions not stored within the Project’s main -        code repository will comply with the contribution process and license -        terms for the applicable Upstream Project. - - c. If an alternative inbound or outbound license is required for compliance with the -   license for a leveraged open source project or is otherwise required to achieve the -   Project’s mission, the TSC (but only with DreamWorks’ approval) may approve -   the use of an alternative license for specific inbound or outbound contributions on -   an exception basis. Any exceptions must be limited in scope to what is required -   for such a purpose. To request an exception, please describe the contribution, the -   alternative open source license(s), and the justification for using an alternative -   open source license for the Project. - - c. Contributed files should contain license information, such as SPDX short form -   identifiers, indicating the open source license or licenses pertaining to the file. - -**7. Amendments** - - a. This charter may be amended by a two-thirds vote of the entire TSC, subject to -   reasonable approval by DreamWorks Animation L.L.C. diff --git a/tsc/icla.md b/tsc/icla.md deleted file mode 100644 index 0958dc4..0000000 --- a/tsc/icla.md +++ /dev/null @@ -1,37 +0,0 @@ -Individual Contributor License Agreement ("Agreement") - -Thank you for your interest in the MoonRay (aka OpenMoonRay) Project (hereinafter "Project") -which has selected the Apache License, Version 2.0 (hereinafter "Apache 2.0 License") for its -inbound contributions. The terms You, Contributor and Contribution are used here as defined in -the Apache 2.0 License. - -The Project is required to have a Contributor License Agreement (CLA) on file that binds each -Contributor. - -You agree that all Contributions to the Project made by You shall be licensed to the Project -under the Apache 2.0 License, and that You agree to, and shall be bound by, the terms of the -Apache 2.0 License. - -By making a Contribution to the Project, You certify that: - - (a) The Contribution was created in whole or in part by You and You have the right to -   submit it under the Apache 2.0 License; or - - (b) The Contribution is based upon previous work that, to the best of Your knowledge, is -   covered under an appropriate open source license and You have the right under that -   license to submit that work with modifications, whether created in whole or in part by -   You, under the Apache 2.0 License; or - - (c) The Contribution was provided directly to You by some other person who certified (a) -   or (b) and You have not modified it. - -By making a Contribution to the Project, You acknowledge and agree that the Project and the -Contribution are public and that a record of the Contribution (including all personal information -You submit with it, including Your sign-off) is maintained indefinitely and may be redistributed -consistent with the Project or the Apache 2.0 License. - -Signature: __________________________________________ - -Name: _______________________________________________ - -Date: _______________________________________________