Spacewalk: building a patch culture

People behave as they see others behave. If people on a mailing list are civil, then newcomers will try to be civil. If people on a mailing list are snippy, then newcomers will feel justified being snippy.

And if people submit patches to a mailing list, and those patches are treated well by the engineers who receive them, then newbies will be more comfortable submitting patches to that list.

In the past few months, we have seen two newcomers to the Spacewalk project: Joshua Roys of Georgia Tech Research Institute, and Maxim Burgerhout, sysadmin from parts unknown. (I hope they won’t mind being discussed in so public a way.) Let’s see how they joined up.

Maxim Burgerhout’s very first post to spacewalk-devel list, in April, was a patch (0). It was a simple patch to rhncfgcli_verify.py, which is part of Spacewalk’s built-in configuration management. Honestly, so many people use puppet and cfengine these days, I don’t expect many people to be using Spacewalk for configuration management. But its one advantage is that it is quite well-integrated, so it’s worth a look. Maxim is clearly a power user of the rhncfg functionality, but hacking code is only an occasional thing for him. In his words, “I usually spend my time being an sysadmin, so I hope I’m doing this ‘sending patch’ stuff the right way. ;-)” Which implies that this was Maxim’s first-ever patch sent to a mailing list! W00t! Since then he has submitted another couple of patches, and is thus a member in good standing of the Spacewalk team.

Joshua Roys, from Georgia Tech Research Institute, made his initial post to spacewalk-devel list in March 2009 with a simple patch fixing bootstrap scripts to retrieve a server cert using SSL (1). It wasn’t quite the right idea, as Jan Pazdziora gently pointed out, due to a (very common) chicken-and-egg problem with the cert.

Then in April, Joshua dug into a tricky issue with oracle-instantclient-selinux, for which Jan publicly thanked him (2).

On May 28th, Joshua posted the largest patch ever offered by a volunteer contributor to Spacewalk (3) — a massive undertaking, in Joshua’s words, “to make the life of government Information Assurance teams easier on Linux.” This patch, essentially a complete new feature, also came with detailed descriptions of the new functionality, including screen shots (4). He has followed it up with a few patches since, expanding the initial functionality.

Spacewalk is a daunting codebase. I know, because I was one of the original engineering managers for that codebase, and trying to dig back into it after four years is painful. Still, dig into it I shall, in the hopes of making it a little more accessible for the next guy.

Which makes it all the more impressive that Joshua was able to make such invasive changes to such a huge codebase. Why did he do it? Simple. He needed the functionality, so he wrote it, and he needed other people to support it, so he shared it.

I would argue that creating a strong “patch culture”, which the Spacewalk engineers did from the day they launched, is part of what is making such successes in Spacewalk possible now.

(0) https://www.redhat.com/archives/spacewalk-devel/2009-April/msg00029.html
(1) https://www.redhat.com/archives/spacewalk-devel/2009-March/msg00104.html
(2) https://www.redhat.com/archives/spacewalk-devel/2009-April/msg00088.html
(3) https://www.redhat.com/archives/spacewalk-devel/2009-May/msg00121.html
(4) http://www.stl.gtri.gatech.edu/jroys/

Spacewalk: building a patch culture

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s