非维护者上传到 Hackage答案

【问题标题】：Non-maintainer uploads to Hackage非维护者上传到 Hackage
【发布时间】：2012-02-24 17:47:40
【问题描述】：

我有一个关于 Hackage 的包，它依赖于第三方包，它不是基于较新版本的 GHC (>= 7.2) 构建的。只需一行补丁（LANGUAGE pragma）即可解决其他软件包的问题。我两次将补丁发送到上游，但没有收到任何反馈。问题是我的包在依赖修复之前都无法安装。

我本可以上传固定版本的依赖包（有一个小版本凸起），但我想听听社区对此类非维护者上传的态度。同样，我不想更改库接口，我只是添加一个新的编译标志以使其再次可构建。

是否允许和容忍非维护者上传到 Hackage？
Hackage 上的包的分叉何时是更好的方法？

【问题讨论】：

虽然这是一个重要的问题，但我不确定这是进行这场辩论的最佳场所。也许图书馆列表会更好，或者haskell-cafe？
我不读haskell-cafe，重新订阅只是问一个问题太麻烦了。人们还可以在 SO 上投票，这是了解社区共识的好方法（一段时间后），可能会出现新的答案，但几天后人们很少在邮件列表中回答。
也许我们应该在Haskell wiki 上创建一个页面来解决这个问题。
最近有关于haskell-cafe关于简化所有权变更流程的讨论：groups.google.com/forum/#!topic/haskell-cafe/SlWfpCabuR0

标签： haskell hackage

【解决方案1】：

允许非维护者上传包（可能存在许可证问题，但大多数包（如果不是所有在 hackage 上的包）都具有允许这样做的许可证），但当然通常不会这样做。如果出于善意并通过合理的程序进行，则可以容忍。如果您联系维护人员并且在 n 周内没有得到任何回复（我不确定 n 的适当值是多少，我会说不少于 3），那么您可以选择自己上传新版本，然而，在邮件列表上讨论这一点似乎更谨慎。如果包看起来被遗弃了，甚至接管维护权——当然在再次联系维护者之后，给她/他时间做出回应——可能是适当的行动，但这绝对应该与社区讨论（haskell-cafe 或邮件列表，例如）。是喜欢非维护者上传还是分叉必须由您自己判断，我个人倾向于认为分叉踩到的人更少。

但是，如果我们知道涉及哪个包裹并可以查看具体情况，则可能会做出更有根据的答复。

【讨论】：

好的，我会等到一个月到期，然后在上传之前在邮件列表中询问。该软件包看起来并没有被废弃，它在 2011 年收到了两次主要版本更新，以及几次次要版本更新。

【解决方案2】：

对于您怀疑仍在维护但作者暂时失踪的软件包，分叉是侵入性。所谓侵入性，我的意思是，一旦原作者在主线上恢复工作，其他程序员可能会拿起你的 fork，然后不再回到主线。

对于原作者离开 Haskell 社区的包，我个人的看法是，如果你打算进一步开发，最好 fork 包。分叉可以防止继承问题，例如 Parsec 中发生的那些许多开发人员不想更新的问题，因为在一段时间内，继承者比原始版本更慢且文档记录较少。

在所有情况下，在 Cafe 上询问是最好的，无论人们是否选择不关注它，它仍然是 Haskell 社区的中心。

对于问题中的特定情况，虽然 Hackage 上的东西可以编译，但没有规则说它们必须编译。依赖于损坏包的包可以简单地将损坏的依赖项的更改说明放在其首页，即 “此包依赖于损坏的 LambdaThing-0.2.0，修复 LambdaThing 将...添加到文件Lambda.hs"

【讨论】：

【解决方案3】：

我想说，查阅有关特定包裹和失踪人员的邮件列表是一个非常好的主意。我从它的原始所有者那里获得了 haskell-src-meta 包的控制权，但只是在咨询了列表和 IRC 之后，他们向我保证 Matt Morrow 已经失踪了几个月并且没有人知道原因。

在我看来，只有在达成共识的情况下才应该更改包所有权，或者至少应该努力找到一个。在 Hackage 软件的开发版本中，据我了解有访问控制，只有管理员才能进行这种干预。

【讨论】：