People often configure Hudson to start a new build whenever a change is made to the repository. In fact, this is often considered central to the practice of continuous integration.

There are two ways to achieve this. One is the "pull" model, where Hudson periodically reaches out to a Subversion repository to see if there is any changes. The other is the "push" model, where you make the Subversion repository reach out to Hudson.

Both approaches have trade-offs. The pull model is easier to configure, since you can do this entirely from Hudson. But this comes at the expense of increased load to the Subversion server. Even though the overhead of Subversion polling is relatively low, as you add more projects to Hudson and increase the polling frequency, the overhead may get non-trivial (imagine the number of Hudson pollings that the poor java.net Subversion server gets, for example.) A more serious downside, in my opinion, is that this increases the delay from your commit to a build. For example, if your build just takes 5 mins, then even if you poll every minute, you pay on average 30 seconds delay before a build starts — a 10% overhead!

A few weeks ago I passed a job listing that I had found through one of my many Google Alerts for Hudson-related queries to Andrew (abayer), following up on one of those job listings Andrew recently signed an offer to join the nice folks over at Digg to be their resident "build guy." On its own I thought "great for Andrew!" and nothing more, then I saw this thread on reddit which poses the question:

Anyone here a build engineer, or part of the build team? Could you please share your experience?

It seems, to me at least, the notion of "release engineering" is making a come-back, particularly in the aging "Web 2.0" world where companies like Digg, Facebook, Reddit, Twitter, etc are anywhere from five to ten years old. As these companies have aged a couple of important things have happened, their code-base has aged increasing the possibility of bitrot, but they have also expanded in terms of headcount. Start-ups that might have once slighted larger corporations like Oracle, Cisco VMWare and IBM for their burdensome process and longer release schedules now find themselves ensnared with massive code bases, larger development teams and complicated deployments.

Rarely do I ever get mail, let alone mail I like, so I was quite excited when a shipment of stickers from Hudson HQ arrived yesterday. I'm certain you're thinking to yourself "what does this guy need hundreds of Hudson stickers for?" Fact is, I don't! They're not for me, they're for you!

I am willing to mail stickers vast distances to you (with some conditions)

Conferences

If you're presenting at a conference or otherwise would like some Hudson stickers to go around, email me with a rough estimate of how many you need. The only condition being that you tell me all about the event and how Hudson was received after the fact (this may involve an interview).

User Groups

If you email me requesting some stickers for a user group, I'll need an estimate of how many folks attend meetings. Depending on supplies, I may send you a little more than requested to be shared.

Companies

If your company wants some Hudson stickers, I'd be happy to oblige, and of course I always appreciate stickers, pens, branded bouncy balls, etc (see: swag) in return!

People who like stickers

If you're just a fan of Hudson, stickers, or both, I'll still gladly mail you a few stickers with the condition that you take pictures of where the stickers end up (and maybe of your Hudson install) and either email me some cool pictures or post them to Flickr (tagged: "hudsonstickers")

I will be stuffing envelopes in my free time, so there may be a slight delay.

A couple weeks ago in the post outlining the release of Hudson 1.347 I mentioned that Alan Harder (a.k.a. mindless) had undertaken a deprecation-crusade; that is to say Alan has taken it upon himself to rid Hudson's code-base, particularly in the plugin area, of older code. One of Alan's branches old-data-monitor was merged into trunk with r28147 bringing with it some changes to help migrate older plugin datasets to newer formats.

When I reached out to Alan earlier today on IRC (#hudson on the Freenode) about the subject he agreed that polling the community for beta testers would be a good idea; this is where you come in. Per Alan's message to the dev@ mailing list:

Visit your "Manage Hudson" screen to see if the notice about old/unreadable data appears. I'll be curious to see which of the old deprecated data structures are actually out there in people's XML files.

Instead of waiting for the release candidate to be packaged Wednesday evening, I've gone ahead and published the artifact from build #4544 which can be downloaded here: hudson.war

If you have an old Hudson installation with, testing this build would be incredibly useful. Alan went on to say:

If people find issues with OldDataMonitor, they should file them at issues.hudson-ci.org in "core" component and assign them to "mindless".

This change does not mutate any data (or at least it shouldn't) so it should be safe, be on the look out for exceptions in Hudson's log on startup.

Michael Donohue, a Hudson developer who has taken on the role of master bug triage guy for Hudson, does something regularly which I've really come to appreciate as a Hudson developer myself: he sends out emails to the dev list with the top 10 voted issues at that time. This gives those of us in the Hudson development community a good sense of what's really important to our users, which in turn helps us decide where to focus our efforts. If you're interested, you can see the top voted issues over at our JIRA server.

A good number of those issues have been high on the list for a while - I'm actually in the early stages of work on a plugin to answer HUDSON-682, the current #1 most voted-for issue, two and a half years after it was opened. But I'm sure there are some equally useful features Hudson users would like to see added which aren't on that list. So I'm asking you, dear readers: what are you looking for in Hudson that isn't already there? Take a look around the existing issues - you may find a request that fits what you want lurking just out of the top 10, needing only your vote to push it into the spotlight. If no one's yet created an issue requesting your desired feature, well, create one.

Or, better still, write a plugin or contribute a patch yourself!

Editor's Note: If you're interested in writing a plugin, you can check out Hudson's wiki and/or this guide on the subject.

Andrew Bayer (abayer) has been a contributor to Hudson since early 2009, contributing to the ClearCase plugin, Hudson's core and a small number of other plugins.