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

Question

这个问题的灵感来自于Duncan Murdoch在r-devel邮件列表中回应关于Sweave的错误报告的评论:

这是在R-patched中修复的.(如果更多的人测试了测试版,它将在2.12.0中得到修复......).

老实说,出于多种原因,我已远离beta -aka开发版本,这些是我听到更多人的原因:

1. 我有点害怕它会以某种方式导致与我目前的R发行版冲突.因为我需要它来工作,不得不经常修理它是我无法向老板解释的时间
2. 我不知道如何有效地测试.我认为我能想到的每一项测试都已经由开发团队运行.
3. 我仍然觉得很难弄清楚什么时候是一个bug,而且(最常见的)这是我自己的愚蠢行为.

但正如我所理解的那样,这将是对R社区的宝贵贡献,而且如果我能以某种方式将其融入我自己的工作中,我也愿意进行一些测试.我正在考虑将测试版保留在一边并通过它运行我的脚本以及检查.保存构造的对象可以快速,轻松all.equal()地查看是否有错误.

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

我也想在我们的部门推广这一点.除了"现在是回馈社区的时候"之外,为什么测试贝塔值得努力的其他任何好理由呢？我怎样才能反驳上面给出的论点？

编辑:

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

Answer 1

我怕你误会.这一开始可能不是直截了当或明显的,所以这可能会有所帮助:

• "修补"不是"测试版".修补是R 2.12.1将是什么.

• 没有冲突.它下降了2.12.0.

• 这是一个单独的下载,每晚都可以从这里获得.

• 这不是r-devel而是r-patched.

• 作为用户,我们也有责任测试预发行版.所以,如果有的话,在一个理想的单词中你会安装R-patched ---以及R-devel!

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