In August Productions

I've been thinking a bunch about email and mailing lists recently... about how to deal with them, how to follow the ones that are important but not get drowned in a sea of email noise. I have a non-tech email account which is where friends mail me personally and where I handle theatre-related stuff. I do not receive a stupid amount of email on this account, and I am almost always interested in reading the messages that arrive there. So on my inaugust.com email address, I've been considering unsubscribing from all mailing lists and setting both Launchpad and github to stop emailing me most things.

For Launchpad and github, most things I care about have status pages of some sort: lists of bugs or branches I need to attend to or whatnot. I really don't need to get an email every time someone files a bug - it's noise.

Mailing lists are the trickier one, because so many open source projects are centered around them in one form or another. For a long time I kept filters to file things in to mail folders - but then I realized that I'd forget about large numbers of them and would never read them. So then I removed those filters so that they'd hit my inbox and I'd read the stream - but that's obviously too much.

I'm starting to think that they are all a complete and total waste of time in terms of existing in my inbox. Back in the good old days of the internet, a lot of that sort of conversation occured over NNTP, which thankfully also had the idea of expiring messages from the newsgroup after a period of time. The separation here was really nice, as it separated messages in general from message TO ME. RSS feeds into a feed reader might be an option - but it doesn't model the "Oh, I noticed a thing I should respond to which now needs to be a conversation I'll follow" workflow.

I don't know the answer - but the current stream of crap hitting my Inbox is fully problematic. (And no Stewart, notmuch will not help my problem here)

Rackspace has been busy over the last year, funding both the Drizzle project and the OpenStack project. I've been lucky enough to be involved in both, and I couldn't be more pleased and proud of the stuff that's come from both projects.

What about synergy though?

Well, it turns out that it's pretty easy to use Drizzle as your database for two of the three current main OpenStack components. Glance, the Image Registry and  Nova the Cloud Computing Fabric Controller, both use SQLAlchemy to manage data that needs to go into a database.

There's one prerequisite you need to get up and running, and that's SQLAlchemy 7, which is currently in beta. SQLAlchemy 7 introduces a Drizzle dialect, which tells the ORM how to map properly to Drizzle datatypes and the like. Once you've installed SA7, it's as simple as creating a schema to stick data in and the changing the sql_connection setting in either your glance.conf or your nova.conf file to be of the form "drizzle://user@host/database" and you'll be off to the races. From by-hand testing I've been doing, all seems to work properly.

What about more automated testing?

I've been doing some poking at the test suites for both glance and nova, because I'd like to be able to set up some Jenkins jobs to ensure that running Glance and Nova on top of Drizzle (and to be honest MySQL and Postgres) is actually something that's tested on each commit. At the moment, the Glance test suite works fully. The Nova test suite makes a few assumptions about sqlite files, so I'm working up a patch to have it not copy in blanked out sqlite files as part of the test suite. But once that's done, I'll get the whole thing up and going in Jenkins and then make sure that Drizzle (and MySQL and Postgres) can actually handle everything that the SQLAlchemy layer theoretically means we don't have to worry about it. (And for the record, I haven't had to change any code anywhere other than in the test runners, and that was just to support being able to set that option - so SQLAlchemy has pretty much held up to its end of the bargain) 

I just made a patch to the OpenStack tarmac instance which was merged back into upstream trunk. There is now an option (which we are using) which removes the requirement for a separate commit message to be present on the merge proposal before an approved proposal can be merged. It will still use an explicit commit message if it's there, but if it's not, it will happily use your merge proposal description as a commit message.

I do implore you though - if you're the type of person who likes to write 10 page merge proposal descriptions, please also add a short commit message.

Launchpad has two facilities for filing tasks that need to be done in a source tree, Bugs and Blueprints. I've spoken to folks who think the two should be collapsed in to one thing, and folks who think they need to remain separate. I'm in the latter camp, so I thought I'd weigh in real quick with a quick explanation of what I think the difference between the two is. Whether they are fundamentally the same object in the backend object model is irrelevant to me - I'm talking about developer workflow and thought.

In my view, it's really simple:

• A Bug is a record of something that needs to be done - the what
• A Blueprint is a record of how something will be done - the how

If you accept that premise, then you can have a task that has both a bug and a blueprint associated with it. Or you could have a bug with no blueprint (sometimes stating the problem implies the solution) It makes less sense to have a blueprint without a bug - but we do this as a shortcut often times because launchpad doesn't have an automatic 'create a bug for this' feature for blueprints. On the other hand, many of the blueprints the Ubuntu project works with during UDS planning aren't really things with bugs - unless you consider them all to be hows of solving bug#1. Or perhaps there is a missing or merely implied definition of the what for many of them, which might mean that the discussion of how meanders for a little bit.

I think the current structure of blueprints backs me up here. It is intended that a blueprint have a wiki page (implying that perhaps the information might be longer in form) and blueprints have a wonderful dependency graphing feature - which is quite useful for project planning ... "to accomplish this (bug#1) I'm going to do this (blueprint#1) which depends on these other things being done first (blueprint#2 and blueprint#3)"

Additionally, blueprints having an associated wiki page implies that anything with a blueprint is something that should turn in to documentation. If you're writing up a description of how you're going to do something, then perhaps that means when you're done you've written a description of how or why you actually did something, which is sort of what internals documentation is, right?

Now - can things be better with blueprints? Of course. There was discussion at the last UDS of having blueprints have a merge-request style discussion/approval process, which I would whole-heartedly approve of. Additionally, the wiki element could be baked in to the blueprint, and bzr branchable.

But I strongly believe that both serve a strong and fundamentally different purpose.