r - 为什么以及如何作为普通用户有效地测试 R 的 beta 分布？

Question

这个问题的灵感来自于邓肯默多克在 r-devel 邮件列表中对关于 Sweave 的错误报告的回应:

This is fixed in R-patched. (It would have been fixed in 2.12.0 if more people tested the betas...).

老实说，出于多种原因，我一直远离 beta -aka development- 版本，这些是我从更多人那里听到的原因:

我有点害怕它会
以某种方式引起与我的冲突
电流 R 分布。因为我需要
对于工作，必须定期修理它会造成损失
时间我无法向老板解释

我不知道如何测试
有效地。我估计每次测试我
可以想出已经
由开发团队运行。

我还是觉得很难算
当某事是错误时，并且
当(大多数情况下)是我自己的
愚蠢开始了。

但据我所知，这将是对 R 社区的宝贵贡献，如果我能以某种方式将它融入我自己的工作中，我也愿意做我的一部分测试。我正在考虑保留测试版并通过它运行我的脚本以及检查。保存构建的对象可以快速轻松地 all.equal()看看有没有问题。

有人对我如何以最少的努力和最大的效率帮助测试有更多/更好的想法吗？

我也想在我们部门多宣传一点。除了“是时候回馈社区了”之外，还有什么其他好的理由证明测试 Beta 是值得的？我如何反驳上面给出的论点？

编辑:

正如 Dirk Eddelbuettel 在评论中指出的那样，交易的一部分是阻止 Windows 中的路径变量。我对此有一些想法，但也非常感谢有关如何实际组织计算机以测试 R-devel 版本的指示。

Answer 1

我怕你误会。起初这可能并不简单或明显，所以这可能会有所帮助:

“修补”不是“测试版”。补丁是 R 2.12.1 的内容。

没有冲突。它适用于 2.12.0。

它是一个单独的下载，并且是每晚构建 available from here .

这不是 r-devel，而是 r-patched。

作为用户，我们也有责任测试预发布版本。因此，如果有的话，在一个理想的词中，您将安装 R-patched --- 以及 R-devel!

测试可以像安装另一个版本一样简单，将其保留在您的路径之外，然后从脚本动态调整 PATH 和 R_HOME。测试意味着在您的代码和数据上运行它，以防止您在新代码发布后被错误所困扰。