维护者提示¶
维护 WebKit 移植版本是一项艰巨的工作。以下是一些可能有所帮助的建议。
关注项目¶
缺陷跟踪是任何软件项目最重要的任务之一。所有 WebKitGTK 和 WPE WebKit 开发者都应在 Bugzilla 电子邮件偏好设置中关注 `bugs-noreply@webkitgtk.org` 用户。当 WebKitGTK 或 WPE WebKit 产品中创建所有缺陷时，此地址会自动抄送。如果报告其他组件的缺陷，您应该手动抄送此地址。这样，您就可以关注其他开发者正在做什么。跟踪缺陷可能会非常耗时，因此通常只快速浏览与您次要相关的缺陷是有意义的，但如果您根本不关注共享地址，那么您将无法了解当天重要的缺陷和问题，并且您将无法成为一名高效的开发者。
不时查看保存的搜索也很有用。在 Bugzilla 的保存的搜索偏好设置中，您可以订阅其他人共享的搜索，或创建自己的搜索。例如，大多数开发者都将受益于订阅 GTK/WPE 缺陷搜索，并时不时地查看它。那里还存在其他有用的搜索，用于缺陷的子类别，包括可访问性缺陷、字体缺陷、多媒体缺陷和网络缺陷。在此订阅搜索不会影响您收到的电子邮件；它只会创建一个指向您 Bugzilla 页脚中搜索的链接，您可以在那里不时手动查看搜索结果。
零警告¶
如果在构建过程中出现编译器警告，开发者可能很难注意到编程错误何时引入了新的警告。因此，确保构建没有垃圾警告对于避免错过可能指示严重缺陷的真实警告非常重要。由于警告因使用的编译器、编译器版本、构建类型（调试版与发布版）和构建选项而异，因此只有您才能负责修复特定构建配置中出现的警告。您有三种选项来修复警告：(a) 通过更改代码以不再触发警告（首选）；(b) 使用 Source/WTF/wtf/Compiler.h 中定义的 IGNORE_WARNINGS_BEGIN() 和 IGNORE_WARNINGS_END() 宏或其中定义的相关宏来抑制警告（次优选项）；或 (c) 将编译器标志添加到相关的 CMakeLists.txt 以禁用警告（作为最后手段）。例如，Source/WebKit 子项目是使用 -Wno-unused-parameter 构建的，这在 Source/WebKit/CMakeLists.txt 中指定。
如果您看到新的警告出现，请花时间修复它。引入该警告的开发者可能正在使用与您不同的编译器或构建配置进行构建，其他开发者肯定会感谢您花时间保持构建的干净。
当发布新版本的编译器时，通常会有许多新警告。可能需要一两天的时间才能使构建再次没有警告。这是为了确保 WebKit 质量而值得付出的努力。
自 255961@main 起，在开发者模式下警告默认是致命的。要禁用此功能，请使用 build-webkit --no-fatal-warnings 或将 -DDEVELOPER_MODE_FATAL_WARNINGS=OFF 传递给 CMake。对于非开发者构建，警告绝不应该是致命的，因为这会给用户带来极大的困扰。
零未审核拉取请求¶
您最终负责找到审阅者以确保您的拉取请求得到审阅，无论是通过在 Bugzilla、IRC 还是电子邮件上联系审阅者。没有人可以代劳。您应该时不时地检查您在 GitHub 上的开放拉取请求，并确保您没有积压未审阅的拉取请求。您的请求队列的理想大小是几天内没有旧的拉取请求。
零回归？¶
WebKit 实行零回归政策，这意味着任何提交者如果发现某个提交引入了回归，都可以回滚该提交。话虽如此，请运用常识。如果构建机器人损坏，那是紧急情况，立即回滚有问题的提交，然后再考虑如何修复问题是合理的。如果 WebKitGTK 完全无法工作或遭受了其他严重回归，那么再次强调，立即回滚有问题的提交，以后再提问。但通常问题比较次要，在回滚之前与引入问题的开发者交谈，或者根本不回滚会更有意义。开发者通常不喜欢看到工作被回滚，并且不必要地回滚提交不会让您交到朋友。一个提交在修复一个主要问题的同时引入一个不太严重的问题并不少见；如果盲目遵守零回归政策而回滚一个提交会降低 WebKit 的整体质量，那将是没有意义的。一般来说，跨平台提交只有在回归严重时才应回滚。特定于平台的 WPE/GTK 提交可以更积极地回滚。
安全¶
安全对于一个网页引擎来说非常重要。通常，任何网页内容可以导致 WebKit 崩溃的问题都是安全问题。事实上，几乎每一个崩溃或断言失败都是安全问题。唯一不属于安全问题的崩溃是那些无法通过网页内容触发的崩溃，但这类崩溃在 WebKit 中很少见。幸运的是，并非所有崩溃都同样严重。例如，空指针解引用或发布断言仅仅是拒绝服务问题，而使用后释放或缓冲区溢出则是代码执行漏洞。
在 Bugzilla 中有一个保存的搜索，用于显示安全组件中的开放缺陷，如果您是 WebKit 安全团队的成员，您将可以看到它。然而，由于几乎所有崩溃都是安全问题，大多数安全问题实际上是公开报告的，而不是针对安全组件报告的。
此外，请注意我们的 TestExpectations 中 [ Crash ] 预期是公开的。因此，导致崩溃的布局测试是攻击者开始针对 WebKit 制作漏洞利用的简单蓝图。可接受的导致崩溃的布局测试数量为零。
CVE 请求¶
由于 WebKit 开发者经常修复大量崩溃报告，因此每次解决安全问题时都请求 CVE 是不切实际的。相反，CVE 通常只针对第三方安全研究人员发现的漏洞发布。这是一种对待安全公告的悲观方法，但为每个漏洞请求 CVE 是不合理的。尽管如此，我们偶尔也会为异常值得注意的问题请求 CVE。之前的例子包括 TLS 证书验证问题、WebKit IPC 框架中的消息验证问题，或 WebKit 未能遵守用户配置的代理设置而导致的代理绕过问题。对于不影响 Apple 移植版本的问题请求 CVE，请使用 MITRE 的网页表单，并忽略所有告诉您不要使用该表单而应使用其他 CNA 的说明。如果您尝试从其他 CNA 获取 CVE 而不是使用 MITRE 的请求表单，那只会浪费您的时间。特别是，不要使用 DWF CNA。
公告¶
发布新安全公告的时间是在 Apple 发布 Safari 安全公告之后。如果您负责安全公告，那么除了成为 WebKit 安全团队的成员之外，您还需要关注 security-announce@lists.apple.com 邮件列表，以了解何时发布。有一个用于生成公告的脚本在 webkitgtk.org GitHub 仓库中。
稳定分支¶
WebKitGTK 和 WPE WebKit 共享稳定分支，这些分支在 GitHub 中维护，名称以 webkitglib/ 开头。维护稳定分支是一项繁重的工作，决定回溯移植哪些提交并非总是容易的。我们的目标是回溯移植缺陷修复，而不会意外地回溯移植引入新缺陷的提交，但这有时说起来容易做起来难。通常，回溯移植的提交越多，回归的风险就越大，因此需要谨慎。除了在稳定分支维基页面上提议回溯移植的提交外，我们还成功使用了两种不同的策略来识别其他应回溯移植的提交。
卡洛斯的策略¶
第一种策略，卡洛斯的策略，是简单地审查自上次稳定发布以来主分支的所有提交，并回溯移植所有看起来重要的内容。这是识别尽可能多的缺陷修复提交以进行回溯移植的最全面策略，但它非常耗时，即使您非常小心和熟练，也很容易错过重要的提交。在没有对代码库高度专业化领域的专业知识的情况下，也很难确定某个特定提交是否适合回溯移植。迈克尔认为这种策略在新发布周期开始时效果更好，尤其是在 .0 或 .1 版本发布之前。
迈克尔的策略¶
在稳定分支的生命周期后期，可以考虑切换到迈克尔的策略，该策略侧重于审查最有可能成为重要回溯移植候选的提交。这些包括 (a) 回溯移植到 Safari 稳定分支的提交，(b) 与已解决的安全缺陷相关的提交，当然还有 (c) 特定于平台的提交。
Safari 回溯移植是一个很好的起点，因为这些提交已被 Apple 开发者认定为是回溯移植的良好候选。每个 webkitglib 分支都有一个对应的 Safari 稳定分支。对应的稳定分支是在 webkitglib 分支之前或之后不久分支的。例如，对于 webkit-2.22，对应的 Safari 分支是 safari-606-branch。对于 webkit-2.24，对应的 Safari 分支是 safari-607-branch。值得检查对应 Safari 分支上的每个提交，以考虑它是否适合 webkitglib 分支的回溯移植。大多数回溯移植到 Safari 稳定分支的提交也是 webkitglib 分支的良好候选，除了特定于 Mac 或处理 webkitglib 分支中尚未启用的功能的提交。例如，WebKitGTK 2.24 尚不支持 service worker、WebRTC、EME 或 PSON，因此应忽略这些功能的修复。
特定于平台的提交通常具有 [GTK]、[WPE]、[SOUP]、[FreeType]、[GStreamer] 和 [GLib] 等前缀。这些通常对于回溯移植很重要。不要指望开发者在他们的提交很重要时请求回溯移植；这种情况通常不会发生。
其他回溯移植技巧¶
如果主分支的提交无法干净地回溯移植到 webkitglib 稳定分支，则对应的 Safari 分支提交可能可以干净或更容易地回溯移植。
否则，如果某个提交未能干净地回溯移植，请考虑是否应该从主分支回溯移植其他提交，以便实现干净的回溯移植。例如，如果一个缺陷修复提交依赖于一个重构提交，您也应该考虑回溯移植该重构提交。但要谨慎行事。您必须权衡重构可能在稳定分支中引入新缺陷的风险，与您在尝试回溯移植有冲突的提交时自己引入缺陷的风险。
每当一个提交未能干净地回溯移植时，您应该使用 trac 查看受影响文件的修订历史，或者考虑对文件进行 blame 操作，以查看导致回溯移植不干净的原因。
JavaScriptCore 安全修复通常涉及非常大的差异。当存在冲突时手动回溯移植这些修复通常风险很大。相反，应积极地从主分支回溯移植所有必要的其他提交，以使安全修复能够更干净地回溯移植。
始终在您回溯移植的提交的 git 日志中搜索修订号，以查看它是否在其他提交中被提及。如果修订号在后续提交中被提及，那很可能是因为该修订引入了回归。如果您忘记检查，墨菲定律保证您将回溯移植一个引入已知回归的提交。