InfoQ

InfoQ

InfoQ

En | 中文 | 日本語 | Br

592,113 Apr unique visitors

News

My Bookmarks

Login or Register to enable bookmarks for unlimited time.

The content has been bookmarked!

There was an error bookmarking this content! Please retry.

Jenkins Not Interested in Hudson Reconciliation

Posted by Alex Blewitt on Jun 06, 2011

Sections
Operations & Infrastructure,
Process & Practices,
Development
Topics
Java ,
Languages ,
Build systems ,
Hudson ,
Programming ,
Jenkins

At a recent Jenkins meeting, the discussion turned towards whether a reconciliation with the Hudson project was possible (after the Hudson proposal to move to Eclipse.org was released), and what would be required for that to happen.

The previous meeting had already broached the subject, which resulted in the Possible Jenkins Umbrella Foundations and Hudson/Jenkins reconciliation requirements wiki pages.

It now seems certain that Jenkins has no intention of reconciling with Hudson as part of the move to the Eclipse Foundation, nor moving to other foundations such as the Apache Foundation. Even putting aside interpersonal issues, the weekly release cycle of Jenkins and mastering on GitHub seem to be deal-breakers for any proposed foundation plan.

The Apache Foundation, whilst it has read-only Git mirrors, still masters all of its code on subversion. And whilst an increasing number of projects at Eclipse are moving from {CVS,Subversion} to Git, the master is still done on Eclipse.org hardware (although they are mirrored on GitHub).

The Jenkins community seems adamant that they don't want to follow a formal process, with a number voting against having to follow a specific means (especially to bring new committers on board). This rules out involvement at Eclipse, whose attention to IP cleanliness is what distinguishes it from other organisations. In fact, much of the work on Hudson post fork has been addressing issues such as the removal of LGPL dependencies from the codebase, which is a necessary step for migration to either the Apache or Eclipse foundations. All of the LGPL dependencies have been removed from Hudson, with the exception of XOM, an XML processing library.

Chris Aniszczyk posted some thoughts on the proposal at the time, and followed it up with a description of the Eclipse process, which shows that projects at Eclipse can release frequently. Mylyn, for example, releases every quarter and EGit/JGit releases every couple of months.

So a combination of a strong desire to remain at GitHub, to not follow any formal development process and to release weekly will prevent Jenkins from moving to either Eclipse or Apache Foundations. Indeed, there has been no comment by anyone from Jenkins (or CloudBees) being interested on joining the Eclipse Hudson proposal; but there have been plenty of commentators who don't want to see Hudson succeed at Eclipse.

Where does this leave the projects now? Had Oracle been able to move faster in the first place, perhaps the fork would not have happened in the way that it played out. However, the two projects have continued their respective trajectories post fork, and whilst it's true that Jenkins has far more frequently releases than Hudson, both groups argue that their release frequency schedule is better for the end consumers.

Ironically, one of the arguments against Jenkins moving to Eclipse was a couple of references to Shawn Pearce's initial experiences with moving EGit/JGit to Eclipse (The Tragedy of Eclipse.org, Eclipse.org JGit Follies Continue). These expressed frustration at some parts of the Eclipse IP process from a documentation perspective. However, since the move to Eclipse, JGit has received more than 1500 commits, and EGit has received more than 1800 commits since the end of September 2009. With the EGit/JGit 1.0 release in the next couple of weeks, no-one can argue that EGit and JGit have not flourished in their new home.

The next Jenkins meeting is due on Wednesday, but it is likely to maintain the current status quo of not moving to a foundation and continuing to release weekly.

  • This article is part of a featured topic series on Java

Related Sponsor

VMware vFabric SQLFire - Test drive the data management system with memory speed, horizontal scalability and a familiar SQL interface

1 comment

Watch Thread Reply

Jenkins Long-term Support (LTS) Release cycle by banos s Posted

  1. Back to top

    Jenkins Long-term Support (LTS) Release cycle

    by banos s

    Might be worth mentioning that Jenkins does have various release strategies. One aimed at those who prefer less frequent releases. In particular the "Long-term Support (LTS) Release" may be of interest to such users: wiki.jenkins-ci.org/display/JENKINS/Release+Pro...

    Reply