Jenkins 不想与 Hudson 和解

人们在最近关于 Jenkins 的一次会议中开始讨论Jenkins 与Hudson 项目和解的可能性（在 Hudson 迁移到 Eclipse.org 提案发布后）以及要想促成和解双方应该做些什么。

此前的会议已经就这个话题展开过讨论，讨论的结果是 Possible Jenkins Umbrella Foundations 与 Hudson/Jenkins 和解需求 wiki 页面。

现在看起来 Jenkins 并不想与 Hudson 和解并一起迁往 Eclipse 基金会和其他基金会，如 Apache。抛开人际关系不谈，Jenkins 每周的发布周期以及在 GitHub 上的主导力量令任何提案都显得那么苍白无力。

拥有只读Git 镜像的Apache 基金会仍旧掌握了其在 subversion 上的全部代码。随着 Eclipse 上越来越多的项目由 CVS 与 Subversion 转向了 Git，这种掌控依旧在 Eclipse.org 硬件上完成（虽然他们是 GitHub 的镜像）。

Jenkins 社区似乎很固执，他们不想遵循任何正式的流程，这一点通过反对遵循特定方式的投票就能看出端倪（特别是引入新的提交者）。这排除了 Eclipse 参与的可能性，他们对于知识产权的态度与其他组织截然不同。事实上，Hudson 分支很重要的一点就是强调从代码基中移除对LGPL 的依赖，无论是迁移到Apache 还是Eclipse 基金会，这都是非常重要的。Hudson 已经移除了所有的LGPL 依赖，除了 XOM ——XML 处理库。

与此同时，Chris Aniszczyk 发表了自己对于提案的看法，同时介绍了 Eclipse 的流程，表明 Eclipse 的项目也能保持频繁的发布周期。比如说，Mylyn 就是每季度发布一次，EGit/JGit 则是每几个月发布一次。

因此，既希望留在 GitHub，又不想遵循任何正式的开发流程并且要保证每周发布使得 Jenkins 无法迁移到 Eclipse 或 Apache 基金会。事实上，Jenkins（或是 CloudBees）没人愿意参与到 Eclipse Hudson 的提案中；但有很多人不希望看到 Hudson 在 Eclipse 获得成功。

这会对项目造成什么影响呢？要是 Oracle 一开始就能快速迁移，或许分支不会沦落到现在的地步。然而，这两个项目仍在沿着各自的轨道发展着，虽然 Jenkins 的发布周期要比 Hudson 更为频繁，但这两个项目的开发人员都在宣称自己的发布周期更适合于最终用户。

颇具讽刺意味的是，针对 Jenkins 迁移到 Eclipse 的一个争议竟然引用了 Shawn Pearce 将 EGit/JGit 迁移到 Eclipse 的初体验（ Eclipse.org 的悲剧， Eclipse.org JGit 的悲剧仍在继续）。文档表明了 Eclipse 知识产权过程的某些地方出现了问题。然而，自从迁移到了 Eclipse，JGit 收到了 1500 多个提交；从 2009 年 9 月以来，EGit 收到了 1800 多个提交。随着 EGit/JGit 1.0 将于不久后发布，没人会说 EGit 与 JGit 不再繁荣。

下一次的 Jenkins 会议安排在周三，但目前的形势表明 Jenkins 仍将维持现状，不会迁移到任何一个基金会，同时继续保持每周发布的态势。

查看英文原文： Jenkins Not Interested in Hudson Reconciliation