Python Testing Cookbook

Python Testing Cookbook

Python Testing Cookbook  //  Follow the development, writing, and production of this Packt Publishing book targeted at Python developers that want to get every ounce of value out of automated testing.

Feb 3 / 1:55pm

Jenkins download available

Download jenkins.war

This makes me very confident that I will be able to revise the recipes using Hudson to instead use Jenkins. The community has moved fast in getting a newly branded release of Jenkins out there! By the time I am doing the rewrites for the relevant chapter, this should have any kinks taken care of.

Maybe you are thinking I am making an opinionated decision? Well, I have an opinion, so yes, that would be an accurate statement. What is my opinion? The people who write, develop, and grow Hudson are the ones that conducted an election and are now carrying out this rename/fork.

I really support people that pick up a shovel to work. Oracle may have customers that use Hudson, but I don't remember seeing any mention of Oracle staff working on Hudson. In my opinion:

  1. SUN (not Oracle) paid someone to work in their spare time to develop Hudson. 
  2. SUN (again, not Oracle) allowed this product that while used internally, to also be released under an OSS license to the world with no desire to patent, trademark, or hold on tight. 
  3. That developer left SUN. 
  4. Oracle bought SUN, and now they want to pull Hudson back into their control

We should follow those that made Hudson happen, not those that decided to pull it in when it was too late. Sorry, but the horse has already left the barn. The only thing Oracle has is the possibility of a trademark on the name. The entire development community has the right to free themselves of this IP entanglement and continue unabated.

To wrap up my opinion, I think the developer community acted openly. They even offered Oracle a significant seat on the governing panel of Jenkins, and were politely refused. Sorry, but I believe Oracle will only garnish a meager amount of revenue from support contracts for this. They should have jumped at the chance to be a part of this.

This is nothing but speculation, but I believe developers that have to choose between these two will pick Jenkins. I would. The product's primary developer is works on it full time and I would expect this to be well supported.

So yet, this is opinionated. I will be proud to support Python developers by showing them a handful of recipes to utilize Jenkins as an option in continuous integration.