From 93d7973b97448537da92b86004a2d7489a777d5a Mon Sep 17 00:00:00 2001 From: "jijoong.moon" Date: Tue, 20 Oct 2020 10:56:43 +0900 Subject: [PATCH] [ ADMIN ] Add code of conduct Add documentaions releate with code of conduct. **Self evaluation:** 1. Build test: [X]Passed [ ]Failed [ ]Skipped 2. Run test: [X]Passed [ ]Failed [ ]Skipped Signed-off-by: jijoong.moon --- Applications/KNN/AndroidManifest.xml | 29 --------- Applications/KNN/build.gradle | 90 ---------------------------- CODE_OF_CONDUCT.md | 53 ++++++++++++++++ CONTRIBUTING.md | 60 +++++++++++++++++++ MAINTAINERS.md | 24 ++++++++ docs/coding-convention.md | 41 +++++++++++++ docs/contributing.md | 69 +++++++++++++++++++++ 7 files changed, 247 insertions(+), 119 deletions(-) delete mode 100644 Applications/KNN/AndroidManifest.xml delete mode 100644 Applications/KNN/build.gradle create mode 100644 CODE_OF_CONDUCT.md create mode 100644 CONTRIBUTING.md create mode 100644 MAINTAINERS.md create mode 100644 docs/coding-convention.md create mode 100644 docs/contributing.md diff --git a/Applications/KNN/AndroidManifest.xml b/Applications/KNN/AndroidManifest.xml deleted file mode 100644 index dd38d057..00000000 --- a/Applications/KNN/AndroidManifest.xml +++ /dev/null @@ -1,29 +0,0 @@ - - - - - - - - - - - - - - - - - - - - - - diff --git a/Applications/KNN/build.gradle b/Applications/KNN/build.gradle deleted file mode 100644 index 7ed60355..00000000 --- a/Applications/KNN/build.gradle +++ /dev/null @@ -1,90 +0,0 @@ -buildscript { - repositories { - jcenter() // or mavenCentral() - google() - } - dependencies { - classpath 'com.android.tools.build:gradle:3.4.1' - } -} - -allprojects { - repositories { - jcenter() - google() - } -} - -apply plugin: 'com.android.application' - -android { - compileSdkVersion 24 - buildToolsVersion '28.0.3' - - defaultConfig { - applicationId "org.freedesktop.gstreamer.nnstreamer.nnstreamermultidevice" - minSdkVersion 24 - targetSdkVersion 24 - versionCode 1 - versionName "1.0" - - - externalNativeBuild { - ndkBuild { - def gstRoot - - if (project.hasProperty('gstAndroidRoot')) - gstRoot = project.gstAndroidRoot - else - gstRoot = System.env.GSTREAMER_ROOT_ANDROID - - if (gstRoot == null) - throw new GradleException('GSTREAMER_ROOT_ANDROID must be set, or "gstAndroidRoot" must be defined in your gradle.properties in the top level directory of the unpacked universal GStreamer Android binaries') - - arguments "NDK_APPLICATION_MK=jni/Application.mk", "GSTREAMER_JAVA_SRC_DIR=src", "GSTREAMER_ROOT_ANDROID=$gstRoot", "GSTREAMER_ASSETS_DIR=src/assets" - - targets "nnstreamer_multidevice" - - // All archs except MIPS and MIPS64 are supported - abiFilters 'arm64-v8a' - } - } - } - - buildTypes { - release { - minifyEnabled false - proguardFiles getDefaultProguardFile('proguard-android.txt'), 'proguard-rules.pro' - sourceSets { - main { - manifest.srcFile 'AndroidManifest.xml' - java.srcDirs = ['src'] - resources.srcDirs = ['src'] - aidl.srcDirs = ['src'] - renderscript.srcDirs = ['src'] - res.srcDirs = ['res'] - assets.srcDirs = ['assets'] - } - } - } - } - - externalNativeBuild { - ndkBuild { - path 'jni/Android.mk' - } - } -} - -afterEvaluate { - if (project.hasProperty('compileDebugJavaWithJavac')) - project.compileDebugJavaWithJavac.dependsOn 'externalNativeBuildDebug' - if (project.hasProperty('compileReleaseJavaWithJavac')) - project.compileReleaseJavaWithJavac.dependsOn 'externalNativeBuildRelease' -} - -dependencies { - implementation fileTree(dir: 'libs', include: ['*.jar']) - testImplementation 'junit:junit:4.12' - implementation 'com.android.support:appcompat-v7:24.0.0' -} diff --git a/CODE_OF_CONDUCT.md b/CODE_OF_CONDUCT.md new file mode 100644 index 00000000..2b8eb32d --- /dev/null +++ b/CODE_OF_CONDUCT.md @@ -0,0 +1,53 @@ +# Contributor Covenant Code of Conduct + +## Our Pledge + +In the interest of fostering an open and welcoming environment, we as contributors and maintainers pledge to making participation in our project based on meritocracy and our community a harassment-free experience for everyone. + +## Our Standards + +Examples of behavior that contributes to creating a positive environment include: + +* Using welcoming and inclusive language +* Being respectful of differing viewpoints and experiences +* Gracefully accepting constructive criticism +* Focusing on what is best for the project + +Examples of unacceptable behavior by participants include: + +* The use of sexualized language or imagery and unwelcome sexual attention or advances +* Trolling, insulting/derogatory comments, and personal or political attacks +* Public or private harassment +* Publishing others' private information, such as a physical or electronic address, without explicit permission +* Other conduct which could reasonably be considered inappropriate in a professional setting + +## Our Responsibilities + +Project maintainers are responsible for clarifying the standards of acceptable behavior and are expected to take appropriate and fair corrective action in response to any instances of unacceptable behavior. + +Project maintainers have the right and responsibility to remove, edit, or reject comments, commits, code, wiki edits, issues, and other contributions that are not aligned to this Code of Conduct, or to ban temporarily or permanently any contributor for other behaviors that they deem inappropriate, threatening, offensive, or harmful. + +## Contributors' Responsibilities + +By submitting a code, you are guaranteeing, up your best knowledge, that +* The content of the submitted code is not patented or you are providing the right to practice the related patents according to the license of NNTrainer to NNTrainer users and developers. +* You have the right to contribute the code; you have the copyright (or the copyright holder has permitted to submit the code to NNTrainer). If your code is done for a employer, the employer may have the right to the code. +* You have tested and verified the code. +* You allow the maintainers to update the license of the project later as long as the update does not conflict with the base code of this project. The base code is the code before your contribution. + +## Scope + +This Code of Conduct applies within official project spaces and official events of the project. +Note that the official project spaces may include more in the future although we have github.com only for now. + +## Enforcement + +Instances of abusive, harassing, or otherwise unacceptable behavior may be reported by contacting the maintainer at jijoong.moon@samsung.com. The maintainer will review and investigate all complaints, and will respond in a way that it deems appropriate to the circumstances. The project team is obligated to maintain confidentiality with regard to the reporter of an incident. Further details of specific enforcement policies may be posted separately. + +## Attribution + +This Code of Conduct is a modified one from the [Contributor Covenant][homepage], version 1.4, available at [http://contributor-covenant.org/version/1/4][version]. + +[homepage]: http://contributor-covenant.org +[version]: http://contributor-covenant.org/version/1/4/ + diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md new file mode 100644 index 00000000..32f55d5d --- /dev/null +++ b/CONTRIBUTING.md @@ -0,0 +1,60 @@ +# Contributing + +## Contributors + +Anyone who has been contributed to the repository by submitting a pull-request and have it reviewed, accepted, and merged by committers is a contributor. + +Each contributor should comply with the [Code of Conduct](https://github.com/nntrainer/nntrainer/blob/main/CODE_OF_CONDUCT.md), this document (CONTRIBUTING.md), and [the Linux Foundation's policies](http://lfprojects.org/policies/). + +Every contributor is able and encouraged to review codes and to participate in other developmental activities. + + + +## Committers + +A committer is responsible for reviewing incoming pull-requests and is able to reject or approve pull requests. Note that contributors may review pull-requests, but they cannot reject it or vote for approval. + +A contributor may become a committer with approvals of more than half of the committers.  + +A committer may be retired by approvals of more than half of the committers. + +Each committer is also a contributor and should comply with the [Code of Conduct](https://github.com/nntrainer/nntrainer/blob/main/CODE_OF_CONDUCT.md), this document (CONTRIBUTING.md), and [the Linux Foundation's policies](http://lfprojects.org/policies/). + +The committers are: + +* Jijoong Moon @jijoongmoon :beer: (maintainer) +* MyungJoo Ham @myungjoo :beer: +* Geunsik Lim @leemgs :beer: +* Jaeyun Jung @jaeyun-jung :beer: +* Sangjung Woo @again4you :beer: +* Wook Song @wooksong :beer: +* Dongju Chae @dongju-chae :beer: +* HyoungJoo Ahn @helloahn :beer: +* Parichay Kapoor @kparichay :beer: +* Gichan Jang @gichan-jang +* Yongjoo Ahn @anyj0527 +* Jihoon Lee @zhoonit + + +## Merging a pull-request + +[How to Contribute # Merge Criteria](docs/contributing.md#merge-criteria) describes how a pull-request may be merged or rejected by committers. + +In the above list, committers with :beer: have merging privilege. + +Granting or revoking merging privileges require the same procedure of electing or retiring a committer. + +Each sub-project may have its own [Maintainers](MAINTAINERS.md#maintainer) in the sub-project. + + +# Links to related information + +## Contributing + +See [How to Contribute](docs/contributing.md) for information about coding styles, making pull requests, and more. + +## Developers + +- See [Getting Started](docs/getting-started.md) for information about building this software. +- See [How to Run Examples](docs/how-to-run-examples.md) for information about building and running examples applications. +- See [How to Use Testcases](docs/how-to-use-testcases.md) for information about running test cases and writing ones. diff --git a/MAINTAINERS.md b/MAINTAINERS.md new file mode 100644 index 00000000..0f745f5f --- /dev/null +++ b/MAINTAINERS.md @@ -0,0 +1,24 @@ +# Definitions of Roles + +## Maintainer + +- A committer that is also an arbiter for other committers in the Github/Git repositories. +- May override merging criteria to merge/close a pull-request or to push/revert a commit. + +## Committer (previously Reviewer) + +- May reject a pull-request, which prohibits merging. "Veto" +- May vote for an approval. +- (Requires merge privilege) May merge a pull-request if it has enough number of approval-votes from committers (2 or more). +- May propose new committers among well-known contributors and vote for new committers +- Vote for a committer removal. +- The ability of reject and merge may be limited to a few subdirectories. +- The list of reviewers and their subdirectories is at [.github/CODEOWNERS]. + +## Contributor + +- Anyone who has sent a pull-request, which is accepted and merged with the full procedures. + +## Note + +We allow anyone to send and review pull-requests (although may be not allowed to vote), or to write an issue as long as they do no harm or break [CODE_OF_CONDUCT.md] diff --git a/docs/coding-convention.md b/docs/coding-convention.md new file mode 100644 index 00000000..d6507b62 --- /dev/null +++ b/docs/coding-convention.md @@ -0,0 +1,41 @@ +# Coding Convention + +## C headers (.h) + +You may indent differently from what clang-format does. You may also break the 80-column rule with header files. + +Except the two, you are required to follow the general coding styles mandated by clang-format. + +## C/C++ files (.cpp, .c) + +Use .h for headers and .cpp / .c for source. +You have to use clang-format with the given [.clang-format](../.clang-format) file + + +## Other files + +- [Java] TBD +- [Python] TBD +- [Bash] TBD + + +# File Locations + +## Directory structure of nntrainer.git + +- **api**: API definitions and implementations + - **capi**: C-APIs (Tizen and others) +- **debian**: Debian/Ubuntu packaging files +- **docs**: Documentations +- **nntrainer**: All core NNTrainer codes are located here +- **nnstreamer**: NNStreamer sub-filter codes for NNTrainer +- **jni**: Android/Java build scripts. +- **Applications**: Examples for NNtrainer +- **packaging**: Tizen RPM build scripts. OpenSUSE/Redhat Linux may reuse this. +- **test**: Unit test cases. We have GTEST test cases. There are subdirectories, which are groups of unit test cases. +- **tools**: Various developmental tools and scripts of NNTrainer. + +## Related git repositories + +- [NNStreamer](https://github.com/nnstreamer/nnstreamer) +- [TAOS-CI, CI Service for On-Device AI Systems](https://github.com/nnstreamer/TAOS-CI) diff --git a/docs/contributing.md b/docs/contributing.md new file mode 100644 index 00000000..45e3f6ed --- /dev/null +++ b/docs/contributing.md @@ -0,0 +1,69 @@ +# How to Contribute + +## Coding Convention +Consistent code conventions are important for several reasons: +* *Most importantly:* To make it easy to read and understand the code. Remember: you may be the only one writing the code initially, but many people will need to read, understand, modify, and fix the code over its lifetime. These conventions attempt to make this task much easier. If the code consistently follows these standards, it improves developer understanding across the entire source base. +* To make it easy to debug the code, with both a system call tracer and GNU debuggers. It should be easy to set breakpoints, view locals, and display and view data structures. +* To attempt to improve code quality through consistency, and requiring patterns that are less likely to result in bugs either initially, or after code modification. + +For more information, please refer to [coding-convention.md](coding-convention.md). + +For C/C++ code, you may apply clang-format with the given [.clang-format](../.clang-format) file. +For C/C++ header files, we do not require strict style rules, but it is recommended to apply such rules. + +We do not have explicit and strict styling rules for other programming languages, yet. + +## Code Reviews and PRs + +You are encouraged to review incoming PRs; regardless whether you are a committer, a designated reviewer, or just a passer-by. + +If you are a committer or a reviewer of the specific component, you are obligated to review incoming related PRs within some reasonable time frame. +However, even if you are not a reviewer (designated by committer or submitter), as long as you are in this project, you need to give feedback on PRs especially if you are working on similar topics/components. + +The submitter has the first responsibility of keeping the created PR clean and neat (rebase whenever there are merge conflicts), following up the feedback, testing when needed. + +### Additional requirements for codes +* Each feature should come with a rich set of test cases that can be executed as unit tests during build. If the feature is more invasive or richer, you need more and richer test cases. Refer to other test cases in /tests directory, which use either GTest or SSAT. +* When new test cases are introduced, the number of new negative test cases should be larger than or equal to the number of new positive test cases. +* For C-code, try to stick with C89. +* For C++-code, try to be compatible with C++14. C++ code should be able to be built optionally. In other words, by disabling C++ build option, we should be able to build the whole system without C++ compilers. +* Avoid introducing additional dependencies of libraries. If you are going to use additional libraries, your codes may be located at /ext/* so that they can be "optional" features. +* If your functions or structs/classes are going to be accessed by other modules or NNStreamer users, provide full descriptions of all entries with Doxygen. +* Passing all the tests of TAOS-CI is a necessary condition, but not a satisfying condition. + +### Merge Criteria + +A PR is required to meet the following criteria. +* It has passed all the tests defined for TAOS-CI. + - This includes unit tests and integration tests in various platforms and different static analysis tools. + - Note that one of the tests includes the "Signed-off-by" check, which means that the author has agreed with [Code of Conduct](../CODE_OF_CONDUCT.md). You may need to refer to later section. +* At least TWO committers (reviewers with voting rights) have approved the PR. + - This is a necessary condition, not sufficient. + - If the PR touches sensitive codes or may affect wide ranges of components, reviewers will wait for other reviewers to back them up. + - If the PR is messy, you will need to wait indefinitely to get reviews. + - Apply general rules of git commits and common senses. + - Do not write a lengthy commit. Apply a single commit per PR if you are new to the community. Have a single topic per commit. Provide enough background information and references. And so on. +* There is no rejections from any official reviewers. +* There is no pending negative feedbacks (unresolved issues) from reviewers. +* A committer with merging privilege will, then, be able to merge the given PR. + + +## Signing off commits + +Each commit is required to be signed-off by the corresponding author. +With properly configured development environment, you can add sign-off for a commit with ```-s``` option: e.g., ```git commit -s```. +[Here is some stories on sign-off](https://stackoverflow.com/questions/1962094/what-is-the-sign-off-feature-in-git-for) + +- How to give the developers zero cost: +```bash +$ vi ~/.gitconfig + [user] + name = Gildong Hong + email = gildong.hong@samsung.com +$ git commit -s +// -s (--signoff) means automated signed-off-by statement +``` + +### What does it mean to sign off commits for authors? + +Including a "Signed-off-by:" tag in your commit means that you are making the Developer Certificate of Origin (DCO) certification for that commit. A copy of the DCO text can be found at https://developercertificate.org/ -- 2.34.1