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.
• Use our Code Review system. Upload your commits there for us to review your changes, suggest improvements and give our opinion about it. We will try to do that as soon as possible.
• 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.

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 the language you are currently writing. 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 spaces.
• Do not exceed the 80-character line length limit if possible. The hard limit is considered at 120 characters and any change exceeding the hard limit can and will probably be rejected.

For participants who have full access (read, write, bypass/admin) on our Code Review server, following rules apply:

• Do not bypass code review for changes to the platform source (repositories such as device, kernel and vendor trees are excluded) unless the change is trivial
• Do not abandon others’ changes without an explanation
• Set the Submit Type to Rebase if Necessary when creating a new project (if not already done)
• Always push to Gerrit if the project is replicated unless the server is not reachable or out of function and your change has priority (prioritized changes are critical bug fixes, build error fixes, etc.), however, before doing so talk to your colleagues about the change or push it to a separate branch/repository before pushing to the main branch. As soon as the server is reachable or working again, push your changes to Gerrit as soon as possible because Gerrit will force-replicate on startup.

For upstream merges following rules apply (these have higher priority than any of the rules and standards above. If one of the following rules would violate any of the rules and standards above this, the violated part of the affected rule/standard is not valid for upstream merges):

• Push upstream merges on top of the current HEAD bypassing Code Review. Use a separate branch for that (e. g. staging/XOS-...) if appropriate.
• Make sure you built the ROM along the upstream changes at least once and tested for general functionality. Fix issues as soon as possible.

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 he is pointing out your mistakes.

Official releases

Official release builds must be built on one of the team members’ or authorized maintainers’ machines 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.

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 or external ones can have CAF merged in).

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.