This page is obsolete, please see Google Summer Of Code 2016 if you're looking for the GSoC 2006 ideas.
This pages lists the project ideas for Google Summer of Code. As Hudson is primarily implemented in Java, a Java fluency is necessary for most of the projects.
In addition to ideas listed here, any other ideas that you may have are welcome. If you have any questions, please feel free to send them to email@example.com.
Pluggable job queue implementation
Queue controls what build/test jobs are executed where and when, so it's a critical piece in the better utilization of the system. There are a lot of other things that can be put into making scheduling decisions, such as trying to keep a project on the set of small machines as much as possible, figuring out the system capabilities through build times, or detecting broken slaves and trying to avoid that, etc. So we'd like to let the community and interested developers experiment with new and different queue implementations, but the current queue implementation in Hudson is monolithic and cannot be replaced.
This project is thus first to make the queue implementation pluggable, then experiment with various queue implementations. The algorithm for queue is open-ended, but if you need some concrete suggestions to start with, consistent hashing is an interesting starting point to improve the locality of builds.
Expect some concurrency programming.
Opening up a Hudson cluster for other uses
Hudson creates a cluster of nodes that it uses for builds and tests, but allowing people to use the cluster for other purposes is useful, too.
To that end, this project is about developing a general-purpose environment for doing a distributed computing. We can discuss what kind of approaches would make sense, but if you need some concrete suggestions to get started, it could include:
- Scripting language like Groovy, patched a little to support distributed computation, as the environment to write a program that spans multiple JVMs. This experiment is already done to some degree to verify the feasibility of this effort.
- A few library calls on this environment for common tasks, such as staging files on multiple JVMs, telling Hudson that the script is using nodes, and/or forking the same process over a large number of nodes.
- A CLI and/or Ant task to make this functionality available to different environments.
Such environment can be used to simplify the administration of Hudson cluster, perform one-off tasks, do distributed testing, and a lot more.
Unified Instant Messenger support
Hudson has several plugins that define connectivity to different IM protocols for notification and bots, but there's not much code reuse between them, and each bot end up looking very different.
This project is about defining an abstract model of instant messenger and the bot, in such a way that the concrete protocol support can be implemented as add-ons. A project should also define several other extension points, such as adding new bot commands.
Support for Jython/JRuby plugin
Plugins have always been one of the strong points of Hudson, but the fact that it has to be written in Java makes it unnecessarily hard to write a simple plugin. So this project is about letting people write a plugin in other languages, whose interpreters are available in JVM (such as Jython and JRuby.)
Such environment can focus on common use cases, such as writing a builder, and need not support everything. We should take advantage of this to further reduce the boiler plate code that a Hudson plugin may require.
Add Windows Integrated Authentication to Hudson
Windows domains and Internet Explorer supports Keroberos-on-SPNEGO based single sign-on solution called "Windows Integrated Authentication". This allows the users of a Windows domain to access a remote web application without typing the password again. There are several pieces in JDKs that implement a part of the protocol, but it's not as readily usable as it should be.
So this project is about wrapping the WIA support into a reusable library, and then integrate that into Hudson. This will benefit Java webapps in general, not just Hudson.
This task is very well scoped out, so the creativity is mainly in implementation and designing it for reusability. Some of you may like that, and some others may hate that.
Wake on LAN support
Work load on Hudson tends to be spiky, and it's rare to see the entire cluster utilized. Therefore, to make Hudson greener, it'd be nice for Hudson to be able to shut down unused nodes and bring them back on as the load changes. There is already an infrastructure in Hudson to do this, but it currently lacks the means to power it off and bring it up.
This project is about implementing a Wake-on-LAN protocol support, which allows us to remotely power on a computer over the network, combined with various platform-specific shutdown techniques, to implement this mechanism.