OSAF just went through a major reorganization. The details can be found on the Chandler Project blog and a variety of other sources and commentary can be found all over.

I'll be staying at OSAF in pretty much my current role, though I'm inheriting quite a few bugs. The way things stand I expect to be working both client and server side due to my familiarity with code in both realms, a prospect I'm excited about. Organizationally OSAF is in the midst of formulating a plan for moving forward and unsurprisingly I've been thinking a lot about where the work I've been doing and plan to do will fit into that.

Operations

Probably the most immediate concerns I (and most of the remaining OSAF staff) have been dealing with so far are those related to day-to-day logistics: keeping the servers running, figuring out how we'll do the things we used to do (build, QA, development) with far fewer people and the loss of knowledge and experience that we've experienced. Some of this will likely be made up for by the continuing involvement of members of the community, but at this point it makes sense to plan as if commitments previously cemented by paychecks are null and void. Personally, I hope we can rebuild many of those relationships over the next year as an open source community-based project, but planning for the future as if those commitments don't exist will strengthen the project regardless of how that process pans out.

To that end, I'm hoping the next few months see movement in a couple directions:

First, I'd like to see us consolidate and automate our QA and build processes to the point that running full regression and unit test suites on any or all of our supported platforms (via our current Tinderbox based system or another similar tool) is a trivial step in development workflows. With the loss of a paid QA department and build/release engineer I think this is the only way to maintain the quality standards and short development cycles we've developed over the past year.

Ideally I'd like to be able to start test runs on any public branch of Chandler Server by filling out a web form. I should have the option to perform a full release upon a successful run and should receive an email upon failure. Details about test failures should be available via the web and archived for at least 2 or 3 weeks. The key to the success of such a system is that developers be able to run arbitrarily detailed test cycles by expending 1-2 minutes of energy on demand. Adding periodic "make sure the tree is green" test runs would be a trivial addition and potentially useful addition.

My first inclination is to build this system using a modern Python web framework like Django. The biggest unknowns (to me) are the details of tying-in to our current system, a point I hope to be able to clarify with other folks inside OSAF in the next week or so.

A second idea that's been rolling around in my head is first class support for Git or another next generation DSCM. I've documented my own experiences with Git and Cosmo here, but I'd love to be able to use OSAF infrastructure for hosting and backing up my public repository.

Next time: OSAF 2.0: Features