如何及时了解 R 包中的已知错误和错误修复？

Question

是否有标准的 R 社区资源来及时了解软件包的已知错误或错误修复？我目前的方法是相当手动的。 （注意：我将其限制为 CRAN - 请参阅注 1。）

我的用例基本上是错误监视和包更新管理。一段时间以来，我平均每个月都会发现几个错误（我会及时向作者报告；-)）。由于我的很多工作都是使用虚拟机完成的，所以当我很好地处理了必要软件包的错误状态时，我倾向于更新 VM 映像。当一堆错误被修复时，我可以删除我的解决方法，这很棒，我更新了图像。当我发现 bug 爆发时，我不会创建新图像。

以下是我目前使用的来源：

• NEWS 文件：许多（但不是全部）包都有 NEWS 文件。这些当然是一个有用的起点。
• 包主页：有些包在CRAN上没有NEWS文件，但在作者网站上单独发布了一个更改日志。
• R 项目托管的邮件列表
• Google 组包
• 与包作者的个人交流
• 包的错误跟踪（例如，开发人员可能使用 Bugzilla）

第一个发现 bug 是一回事（我承认 bug 会发生在我们所有人身上），迟到发现已知的 bug 或者更好的是已经修复的 bug 是另一回事。两者都减慢了我自己的编码速度，但更好的错误监控（也许我们需要一个cdc4R 包:)）会显着减少影响。如果没有标准的更新警报系统（例如，update.packages() 的扩展，它报告哪些软件包可以更新并链接到有关更改的信息），用户的工作就是寻找这些信息。

作为一个试图寻找这些信息的用户，我在上面的列表中是否忽略了一些标准资源？例如，是否有一个 R 邮件列表，开发人员可以在其中发布他们的更改和错误修复？或者是否有一个网站可以汇总这些帖子、发布测试（CRAN 发布 R CMD CHECK 输出，似乎），或者提供一些其他反馈？

---

关于其他资源的一些额外说明，以帮助他人：

• 我看到CRANberries 有一个简洁的diff 包摘要，这对我来说是新的。 （我受到启发考虑在 diff 输出中为 bug 或 fix 使用 grep。）
• R 中的bug.report() 是向 R Core 或包维护者的电子邮件地址发送消息的好方法。
• 值得考虑的几个测试包是：testthat、RUnit 和 svUnit。
• 我个人的“快速测试”是简单地使用digest 来验证结果是否匹配，而无需测试非常大的对象的相等性。

---

注意 1：我标记了这个 cran，因为不可能管理 所有 R 包的世界。对于个人包作者，可以在任何他们喜欢的地方分发包，使用他们喜欢的任何邮件列表或错误跟踪系统等。但是，这超出了 R 的“主流”。我是否要发布一个包并提醒用户对于更改、错误、错误修复，我会选择 CRAN + NEWS + Bugzilla + Google Groups + R-Forge（和/或 RForge）等，但是此列表中是否缺少另一种标准报告机制？

从某种意义上说，此注释还用于询问是否存在鼓励开发人员使用的机制。我怀疑没有标准，因为 R Core 成员的包似乎在错误和更改报告方面做了很多不同的事情。

注意 2：我还添加了administration（尽管其他内容可能更合适），因为这也与管理 R 相关。为了重现性，包的管理非常重要；当有多个用户或更多移动部件时，了解错误和修复成为一项管理任务，以及依赖于外部包的开发的重要考虑因素。如果另一个标签，例如system-administration 更合适，我愿意改变。

Answer 1

不是一个完整的答案，但这里有一些想法。

对于data.table，我们跟踪错误（和功能请求）on R-Forge here。我想您可以（以编程方式）查询 R-Forge 的跟踪器以获取那里托管的所有软件包。无论如何要添加到您的列表中。该网络跟踪器是bug.report(package="data.table") 指向的位置（不仅仅是维护者的电子邮件地址）。

此外，任何人都可以订阅任何<pkgname>-commits@lists.r-forge.r-project.org 邮件列表，以接收 R-Forge 上每个项目的统一差异和提交消息（在提交时）。不过，我不知道包含对任何 R-Forge 项目的任何提交的一般邮件列表。

?data.table 的顶部有一个指向up to the minute NEWS 的链接。如果用户升级，这就是我们与用户沟通最新版本（和开发中）的方式。该链接实时更新；即，“最新”是字面意思。但是，他们必须检查那里！