Adventures in Release Engineering
My dear college (Olin) is feeling small... really small... three-person-class small. But not only small, also student led. This semester I'm lucky enough to be learning release engineering from a war-torn Red Hat release engineering expert (2 year my younger, curses!): Sebastian Dziallas. And I've only got two peers to compete with for attention.
It looks something like this:
Release Engineering
OSS project + student + actual release eng work + mentorship = learning (and fun)
Though I've organized a few hackathons, and heard from OSS community leaders like Jeff Mitchell, but I think this experience will be unique: an In Vivo learning experience. Education with context -- real world context.
So what to engineer? We'll see. I'm looking at NB, a very neat collaborative document annotation tool. Wow, marking up documents, what kind of a paper-pushing bureaucrat am I, you're wondering. No, but it really is a neat tool. Designed for academic reading settings, NB lets students mark up readings with questions and comments. Confusion can be cleared during the reading process. But I'll save you the sales pitch; NB is just a idea at this point.
So how does one start a course on release engineering? Talking about different scales of software production. We outlined our thoughts on startups, large software companies. We came up with the standard fare, startups just run. The code is ugly but it doesn't matter, its all about users. Large corporations are process heavy and move in developed areas. They take shelter in enormous manpower, though sometimes inefficient, can spring to action at the sign of a threat.
Through the semester I imagine we'll have to tailor our understanding to OSS projects, and within that, volunteer projects (as opposed to people who hack on the kernel for their benevolent corporation). I expect to learn a lot about volunteer projects, and the function and passion of their contributors.
Here's to a good semester!