Hi, everyone. If you don't know me, I'm Soren Hansen, I wrote the original bash implementation of VMBuilder, and also wrote and maintain the Python implementation.
I'm still excited about the project, even though I've had extremely little time to work on it for the last many months, and as such haven't had much chance to review patches and give feedback. I hope to be able to change that going forward, and also make some procedural changes that should make me less of an obstacle to getting things done. = Merges and reviews = The first change I'd like to implement is to make the VMBuilder team (this team) the default review team for merge proposals for VMBuilder. This means that new merge proposals will be sent to all members of this team, and everyone can (and should!) comment and vote on them. Both reviewer and submitter become better developers by reviewing code. Everybody wins. Unless someone objects, I'll make this change early next week. = Cleanup and restructuring = As anyone who's tried to write a patch for VMBuilder will know that it's a rather complex code base. Some parts are simply complicated, other parts are confusing because they are where they are purely for historical reasons. Other parts again have simply grown unwieldy over time. I would like for this to change. The goals are to make VMBuilder more easily extensible and to make it easier to come along as a new contributor and write patches. To accomplish this, I have a few ideas: == Event driven VM building == At the moment, VMBuilder's workings are quite static. It starts by setting up a directory structure for the build, creating the disk images, partitions and filesystems, and mounts them. It then asks the distro plugin to do whatever it needs to do to create the VM (which involves a *lot* of steps that are also "static"). When that returns, it unmounts everything, converts the disk images to the target format, optionally deploying the disk image somewhere, cleans up after itself, and terminates. As an alternative approach to this, I'll be adding some kind of hook or event mechanism that will make it much easier for plugins to do interesting things to the build, and the code should hopefully end up more readable and straightforward as a result. == Unit tests and TDD == I've recently developed a small crush on unit tests, and I've started writing some for VMBuilder. Having an extensive set of unit tests will make it easier for new contributors to add new code, as they will be able to quickly test if they've broken any of the existing code. If they manage to break something that the unit tests do not catch, we've simply not written good enough unit tests :) If any of you have experience writing unit tests or with Test Driven Development (TDD), I'd love to get your help. I'm still very much a rookie unit test author, but I very much believe it will make a dramatic impact on the future development of VMBuilder. -- Soren Hansen | Lead virtualisation engineer | Ubuntu Server Team Canonical Ltd. | http://www.ubuntu.com/
signature.asc
Description: Digital signature
_______________________________________________ Mailing list: https://launchpad.net/~vmbuilder Post to : [email protected] Unsubscribe : https://launchpad.net/~vmbuilder More help : https://help.launchpad.net/ListHelp
