Project Standards

Introduction

As a quickly growing project, a lot of responsibility and care has to be taken. We want to unify all our standards in one place, letting all participants, whether as team member, contributor or leader, follow a set of rules in order to strive for a long-living professional-looking project with a friendly and organized atmosphere.

Contribution standards

For team members as well as contributors from outside there are a few standards that should be met on all changes:

• Keep authorship as much as possible. If you are cherry-picking commits from other projects, make sure you don’t change the author. Add a Co-Authored-By label if you think someone deserves extra credit.
• Correct your mistakes. If you made a mistake, be it a typo, wrong authorship, or an error in code, correct it.
• Write clear commit messages if necessary. If a commit is not self-explanatory (self-explanatory commits include translations, correction of grammar/typos, …) or does require further explanation in order to be understood, explain in the commit message body what you did, why you did it, what it affects and how you tested it. That allows everyone to better understand what a commit does.
• Do not force push unless it is absolutely necessary. It's good to create a backup branch or tag before doing so. An exception to this rule is when a branch is in "pre-development" and not ready for public use yet.

As for the code style, following code style standards apply:

• Use AOSP-conforming code style.
• Avoid trailing whitespaces
• Use the indentation type of the file that you are editing. If Tabs are used, do so as well. For new files, follow the conventions of existing files or of the language you are currently writing in. In case there is no convention and there is no other way of finding out the correct indentation type and you can't decide what to use, use 4 spaces.
• Do not exceed the 120-character line length limit if possible.

For admins, project owners/maintainers following rules apply:

• Do not reject others’ changes without an explanation

Standards in the Team

When criticizing, do so constructively. Don't say random things that don't make sense. Talk about things you don't like in a friendly manner. Try finding a solution to problems instead of complaining about it all the time. When pointing out a mistake, do so in a reasonable and understandable matter. Everyone makes mistakes and don’t hate someone just because they are pointing out your mistakes.

Official releases

Official release builds must be built on one of the team members’ or authorized maintainers’ systems and must represent the exact state of the public sources as of the point of time the build was launched. This measure is taken to make sure no unapproved or unwanted changes have been included without prior permission/approval and to ensure reproducible builds.

Team, Contributors and Maintainers

Note on the change of Founders: Instead of only having one founder and additional co-founders, all founders are called the same. This change is to keep consistency and avoid additional hierarchy.

The core team consists of following people:

• Neil Agarwal - Founder, Authorized Maintainer
• Simão Gomes Viana - Founder, Developer, Coordinator, Financial Contributor and Authorized Maintainer
• Daniel Villalobos - Financial Contributor, Coordinator

We want to thank and credit following people for their great support and help:

• Harsh Shandilya - Authorized Maintainer
• Stefan Pruneanu - Veteran OnePlus 2 tester
• Leon - Veteran OnePlus 2 tester
• Paul Larsen - Veteran OnePlus 2 tester, beer lover
• Christian - Veteran OnePlus 2 tester
• Yousvel Lormeus - Veteran OnePlus 2 tester
• Arron Williams - Veteran OnePlus 2 tester and Tim Cook lover
• Kees Sonnema - Web Developer, Graphics-/Web Designer
• Jeremiah Weaver - Graphics Designer and Animation Creator (Boot animation design)
• Sewer - Graphics Designer

Founders have read/write/bypass permissions on the Code Review server.

Authorized Maintainers should have read/write/bypass permissions on their device-specific trees.

Contributors are people who do changes from outside.

Financial Contributors are part of the core team and help paying for infrastructure.

Official Maintainers have the responsibility of frequently (= as much as possible) maintaining device-specific trees. Official maintainers must fulfill specific prerequisites. We reserve the right to revoke authorized/official maintainership at any time.

The team as a whole consists of the core team, platform and app developers as well as authorized maintainers.

Upstream

We base our work off the Android Open Source Project. From 8.0 on, merging CAF is not required and should only be done where necessary. From 10.0 on, CAF shall not be merged into platform repositories (only device-specific, CAF-specific or external ones can have CAF merged in).

We use our scripts in external/xos that are available as the commands mergeUpstream, mergeAospUpstream, etc. to do upstream merges. mergeUpstream merges the repositories given in the upstream attribute in the manifest.

As upstream revision for AOSP, we use one of the latest tags in the format of android-..._r…

As upstream revision for CAF, on 7.1, we use the LA.UM line of the latest MSM SD800-series SoC. From 8.0 onwards, we use the LA.UM tags of the latest SoC.

The manifest is based off AOSP.