提交补丁

提交补丁Submitting Patches

这页介绍全部提交一个补丁到 AOSP 的过程，包括检阅和追踪改变用 Gerrit。

先决条件

• 你先跟着这页的介绍，你将需要建立你的本地工作环境和获取 Android 源文件，介绍跟着"获得开始" 部分，这里。

• 关于 Repo 和 Git 的细节，看版本控制。

• 关于不同角色的信息，你能在 Android 开源社区内发挥，看工程角色。

• 假如你计划贡献代码到 Android 平台，确认读了 AOSP 的授权信息。

• 注意，改变一些上游工程使用 Android 应该直接被制造到这个工程，描述在上游工程。

贡献者

鉴定服务

你能上传到 Gerrit 前，你需要建立一个密码，将标识你用这服务。你仅仅需要做这一次。

• 登录在AOSP Gerrit 服务。

• 转到 Settings -> HTTP Password -> Obtain Password

• 跟着随后（译者注：原为subsquent）页的介绍，和复制粘贴你的密码到 ~/.netrc 里，假如这些是两个密码行，复制两个。

开始一个 repo 分支

每个改变你打算制作，开始一个新分支用有关 git 知识库：

$ repo start NAME .

你能开始几个独立分支在相同时间在相同知识库。分支 NAME 是在本地的你的工作空间和将不被包括 gerrit 或最后的源树。

制作你的改变

一旦你修改源文件(请同时验证它们)保证改变到你的本地知识库：

$ git add -A
$ git commit -s

提供一个细节描述这个改变在你的承诺信息。这个描述将被推到公共 AOSP 知识库，所以请跟着我们的指引写改变明细表描述：

• 开始于一行总结(最大 60 个字符)，接着一个空行。这个格式是用于 git 和 gerrit 各个显示。

  short description on first line
  
  more detailed description of your patch,
  which is likely to take up multiple lines.
  

• 描述将聚焦在它解决什么问题，和如何解决。第二部分是有些可选的当实施新特性，通过可取的。

• 包括一个简短的任何假设或背景信息的笔记，可能是重要的，当另一个贡献者这个特征下一年。

一个独特的改变 ID 和你的名字和 email 作为提供 repo init 期间将被自动添加你的承诺信息。

上传到 gerrit

一旦你承诺你的改变你私人历史，上传它到 gerrit 用

$ repo upload

假如你开始多个分支在相同的知识库，你将被提示选择上传哪些。

一个成功的上传只有，repo 将提供你一个 Gerrit 新页面的 URL。访问这个链接浏览你的补丁在评论服务器，添加评论，或要求具体评论者为你的补丁。

上传一个替换补丁

支持一个评论这看你的补丁和要求一个小修改。你能修改你的承诺用 git，将导致一个新包 gerrit 上有相同的改变 ID 作为原文。

注意，假如你使其它承诺自从上传这个补丁，你将需要手动移动你的 git HEAD。

$ git add -A
$ git commit --amend

当你上传修改补丁，他将替换原本在 gerrit 上和在你的本地 git 历史。

解决 sync冲突

假如其它补丁是提交到源树，和你的冲突，你将需要 rebase 你的补丁在源知识库新 HEAD 顶部。简单的方法做这是运行

$ repo sync

这命令首先取更新从源服务器，然后企图自动 rebase 你的 HEAD 到新的远程 HEAD。

假如自动 rebase 是不成共，你将不得不实施一个手工 rebase。

$ git rebase master

用 git mergetool 可能帮助你处理 rebase 冲突，一旦你成功合并冲突文件，

$ git rebase --continue

自动或手工 rebase 两者之一成功后，运行 repo upload 提交你的 rebased 补丁。

一个提交被批准之后

一个提交使他通过评论和校验过程后，Gerrit 自动合并改变到公共知识库。其它用户将能运行 repo sync 拉这更新到他们的本地客户端。

评论家和验证者

评论一个改变

假如你被分配成一个改变的批准者，你需要确定下面的：

• 这个改变适合这工程的声明目的？

• 这个改变是有效的在这个工程的存在的架构？

• 这个改变介绍设计缺陷将导致问题在将来？

• 这个改变跟着最好的做法已经既定到这个工程？

• 这个改变是一个好的方法实施描述的功能？

• 这个改变是描述一个安全或不稳定风险？

假如你批准这改变，标记它用 LGTM ("我看好")用 Gerrit。

校验一个改变

假如你被分配为一个改变的校验者，你需要做下面的：

• 打补丁这个改变到你的本地客户端用一个下载命令。

• 构建和测试这改变。

• 用 Gerrit 使用公共评论标记这承诺作为"已校验"或"失败"，并且添加一个信息解释问题为什么是确定的。

下载改变从 Gerrit

一个已经被校验和合并的提交经被吓在用 nextrepo sync。假如你希望下载一个具体但不被批准的改变，运行

$ repo download TARGET CHANGE

TARGET 是改变应该被下载到的本地目录和 CHANGE 是改变号在 Gerrit 里的表。更多信息，看Repo 参考。

我如何成为一个验证者或批准者？

简短讲，贡献高品质代码到一个或多个 Android 工程，细节关于不同角色在 Android 开源社区和饰演他们，看工程角色。

差异和评论

打开改变的细节用 Gerrit，点击一个改变的"Id 号"或"主题"。比较既定代码用更新代码，点击"Side-by-side 差异"下的文件名。

添加评论

社区里的任何人能用 Gerrit 添加内联评论到代码提交。一个好的评论将被应用到行或部分代码，它是附在 Gerrit。它可能是一个短的和建设性的建议，关于一行代码可以如何被改善，或它可以是一个解释从作者关于这样的方法代码为什么有意义。

添加内联评论，双击代码有关的行和写你的评论在打开的文本框。当你点击保存，仅仅你能看到你的评论。

发布你的评论以便其他人用 Gerrit 将能看它们，点击发布评论按钮。你的评论将被电子邮件发到这个改变所有有关的各方，包括改变的拥有者，补丁设置上传(假如不同于拥有者)，并且所有当前评论者。

上游工程

Android 利用一些其它的开源工程，例如 Linux 内核和 WebKit，描述在分支和发布。多数工程在 external/ 下。改变应该被上游制作和然后 Android 维护者通知新的上游发布包含这些改变。上传补丁也可以是有用的，移动我们追踪一个新的上游发布，虽然制作改变是困难的，假如工程是广泛的用在 Android 像大多数较大的下面提到的一些。

一个有趣的特别的情况是仿生。许多代码来自 BSD，所以除非改变是编写新的仿生，我们将比较多的看一个上游修理和然后拉到一个全新文件从适当的 BSD。(可悲的是我们有相当一个混合不同的 BSD 在此刻，但是我们希望讲话在未来，和进入一个位置，我们追踪上游更密切。)

ICU4C

所有的改变 ICU4C 工程在 external/icu4c 应该被制作由上游在 icu-project.org/。更多看提交 ICU Bugs 和需要的特征。

OpenSSL

所有的改变 OpenSSL 工程在 external/openssl 应该被制作由上游在 openssl.org。

V8

所有的改变 V8 工程在 external/v8 应该被制作由上游在 code.google.com/p/v8。。细节看 贡献到 V8。

WebKit

所有的改变 WebKit 工程在 external/webkit 应该被制作由上游在 webkit.org。过程开首先备案一个 WebKit bug。这个 bug 应该用于 Android 平台和 OS 领域，仅仅假如 bug 是具体的 Android。Bug 更有可能接收评论者的注意，一旦一个建议修理被添加和测试被包含。细节看 贡献代码到 WebKit。

zlib

所有的改变 zlib 工程在 external/zlib 应该被制作由上游在 zlib.net。