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