Entertainer Media Center

This is a repost, because of the database failure on the server. One might wonder what geeks do when they get bored. Do they write some code, change their wallpaper and idle on dozens of IRC-channels? Well, most of us probably do at least one of ... [More] these things, but when the geek gets really bored, he grabs his camera, takes some photographs of the computers he has and finally writes a blog entry about them. Yes, we are talking about serious boredom here! read more [Less]

I'd like to announce the release of Tarmac, the robotic landing bot for Launchpad. The idea is simple. You have a development focus branch that constantly needs to have branches landed on it, but you're too busy writing your own code to manually ... [More] land them in trunk. Tarmac takes the difficulty out of this by checking your development focus branch for approved merge proposals, and merging them automatically. You can read the README file, grab the Tarmac 0.1 tarball or just get the bzr branch with bzr branch lp:tarmac. This first release is just a little more than "the simplest thing that could possibly work" because I wasn't exactly sure what features were the most important to other potential users. This means feature requests and patches are most certainly welcome (it's why I use Launchpad). Please feel free to file bugs with the features you'd like to see. Tarmac is licensed under the GPLv3. [Less]

For the last few months, I've been entranced with data visualization. I'm convinced that if we take data and find creative ways to visualize it, we'll be able to optimize what produces that data, as well as improve the ways we collect (and thusly ... [More] visualize) that data. One of the things I've wanted to do is hack a little more on bzr-stats, which is a a Bazaar plugin for generating statistics. I used the current trunk of bzr-stats as the groundwork for creating a graph, but the more I think about what I want to do, the more I'm realizing that I probably need to write my own plugin, as I don't think bzr-stats is going to take me where I want to go, and already has a set direction. I'll probably just fork bzr-stats into another project. Regardless, I did a little prototype hacking tonight, and created a pie graph of all committers to a given project, and attached their percentages. The code is ugly, and there are lots of cases I don't yet deal with. For instance, if a user only has one revision, it's still displayed. It'd be nice to set a percentage threshold where you get lumped into an "Other" category, so as not to clutter up the chart. As I get more time, I think it would be cool to see the frequency of commits over time, the various types of contributions (bzr-stats kinda does this), and other types of trend tracking. If nothing else, it'll be cool to see how contributions pick up when Launchpad is open sourced. If you're interested in seeing the crummy prototype code, the branch is here. Update: For those interested, I generated a pie chart for bzr.dev that can be found right here [Less]

So I had this idea for yet another Bazaar post about some more advanced topics, and concepts that my workflow has eventually evolved to incorporate. Among these concepts are shared repositories, lightweight checkouts, and branches with no working ... [More] trees. I'll do my best to explain these concepts, and why I find them to be of benefit, but if there are questions, please feel free to leave a comment and I'll do my best to answer those questions. Shared repositories If you work on a project on a regular basis, you really need to create a shared repository for your project. The basic idea of a shared repository is that you keep all your revisions in a pool together. For instance, you have a local mirror of trunk, and since you share those revisions among your branches, when you create a branch from that local mirror, there's very little overhead to creating the branch, since the revisions don't need to be copied. I keep my various shared repositories in a folder called ~/Projects/repos with each project having its own folders there. When I want to hack on a new project, like, say, Loggerhead, I have the following process: $ mkdir ~/Projects/repos/loggerhead $ cd ~/Projects/repos/loggerhead $ bzr init-repo --no-trees . $ bzr branch lp:loggerhead Now, every time I branch from ~/Projects/repos/loggerhead/loggerhead into ~/Projects/repos/loggerhead/, I don't actually get any new revisions, just a new branch using the old revisions. I don't think this really saves on space too much, but it makes the overhead of branching much cheaper. But wait! Why --no-trees? How the heck do you work if you don't have a working tree? Ah, so now we move on to my next point. Lightweight checkouts So I have two branches in ~/Projects/repos/loggerhead, the mirror of trunk, and a feature branch we just created. Neither that feature branch nor the local trunk have anything in them except the .bzr folder. No working tree. So let's back up a dir to ~/Projects where I keep my working trees. So now I'm going to create a folder to house my Loggerhead working trees. $ mkdir ~/Projects/loggerhead $ cd ~/Projects/loggerhead $ bzr checkout --lightweight ~/Projects/repos/loggerhead/loggerhead $ bzr checkout --lightweight ~/Projects/repos/loggerhead/feature-branch Now I have working trees to work with. When I commit, those committed revisions go back to my branch, and in effect, to my shared repository. Now my working tree is completely separate from the branch itself. I can easily delete the working tree when I'm done with it without losing the branch, and when I decide to delete the branch, I still have those revisions hanging around (in most cases, they've also been merged into trunk). I can also treat that lightweight checkout of the trunk mirror to branch from, merge, commit, etc. as if it was the branch itself, but now there is a clear separation between where I work and where I store my revision data. Using cbranch So we've got two bzr commands to type, the branch command and the lightweight checkout command. If you use bzrtools you can do this in one easy step by setting a few bzr settings in your ~/.bazaar/locations.conf This is what I have set for my directory structure/layout: [/home/rockstar/Projects] cbranch_target = /home/rockstar/Projects/repos cbranch_target:policy = appendpath I also want to set an alias in ~/.bazaar/bazaar.conf to give me lightweight checkouts. [ALIASES] cbranch = cbranch --lightweight Now, when I'm ~/Projects/loggerhead I can just bzr cbranch loggerhead new-feature-branch and bzr will automatically create a branch in ~/Projects/repos/loggerhead and then create the lightweight checkout in ~/Projects/loggerhead bound to that branch. [Less]

Martin Albisetti and I have just hosted a session for Ubuntu Developer Week entitled "Launchpad and Bazaar : How to do it" The logs from this session can be found here. Below are the (now cleaned up) notes that I wrote down while preparing for it. ... [More] The importance of bzr whoami One of the really important things that lots of people forget is to start off with is setting your name is Bazaar. This can be done really easily by doing bzr whoami "Your Name <[email protected]>" It's important that you set this properly, or your revisions aren't going to get your name on them. The email address you set here also needs to be an email that Launchpad knows about (a confirmed address). This way, you get the karma for the revisions, and revision listings in a branch page will link back to your profile. Set a Development Focus Because we're talking about a distributed version control system, there are going to be many branches in your project. It's important to point people glancing at your project to the "trunk" of your project, where all the new fun development it. Once you've pushed up your first branch, it's good to set it as the development focus. Now, new contributors will know where to branch from when they want to, well, contribute. Setting a development focus also tells Launchpad itself what branch is your main branch. For instance, because I have the development focus of Entertainer to lp:~entertainer-releases/entertainer/trunk, every time I do a bzr branch lp:entertainer Launchpad knows to give me the correct branch. It's an alias that can save you a lot of time. I often find myself doing bzr branch lp:randomproject just to get the most up to date source. A quick note about series branches. When you decide to release your software (because you're releasing software often, right?), you'll want to keep a branch of that version. That's what's called a series branch. It'll have point release milestones attached, and when you release those point releases, they'll come out of this branch. The development focus is a glorified series branch. So, in effect, if you create a series branch called myproject-1.1 in the myproject project, you can use bzr branch lp:myproject/myproject-1.1 to get your myproject-1.1 series branch. Since branches are owned by people, you might want to consider creating a team that owns your development focus, and adding people to that team. This keeps your project moving when you go on vacation for two months. It's just a good idea. Workflow decisions Now, you need to decide what your workflow is like. Some projects only have one person working on them. If that's your project, then all you need is one branch, commit, push to Launchpad. That's relatively simple. I do this with a few personal projects. If your project has more than one person, then you've got to make other arrangements. What I suggest is the concept of feature branches. Create a branch specifically for a feature or a bugfix, hack it all together, and merge it into your trunk. This is the optimal solution, and, as far as I'm concerned, the only solution. It's a good idea to see my former post on good Launchpad/Bazaar settings This will take the hard work out of pushing, especially with feature branches. What I usually do is keep a mirror of the development focus branch on my system (with a cron job to update it at regular intervals). When I start a new branch, I branch from that mirror, and start hacking. I try to push at normal intervals, but sometimes I just space that. Merge Proposals and Code Reviews So now you're creating feature branches, because, well, that's the workflow you've chosen. You've written your tests (because you tested first, right?), your feature is ready to land (or so you think). At this point, you should propose it for merging into your development focus branch. No matter how your project handles reviews, it's good that someone at least blesses the revisions that are to proposed to land in trunk. So your branch goes through the review process, comments are made, and eventually, all required reviewers approve of your changes. Now it's time to actually get your branch landed. Someone in the team that owns your development focus will need to merge your branch into their local copy of the "trunk" and then push it up. Once that's happened, Launchpad will mark the merge proposal and your feature branch is also marked as merge. Go hack on another branch! For Reviewers So there are a few different pages that help to know about if you're a reviewer for a project. The first is the activereviews page. If I navigate over to the Entertainer active reviews page you'll see that I have some landing work to do. This also applies to people. If I navigate to my own active reviews page you can see all the branches that I have submitted for review. What if, however, I want to see all the reviews I've done for someone else's branch, and what the status of those branches is. Maybe I set my review vote to "Needs Fixing" and now I need to see if that fixing has occurred. That's when you'll want to check out your requestedreviews page (as of this writing, currently only available in beta, due out in a week). If we go take a look at mine, you'll see that I have some work to do. Bazaar branch formats As Bazaar features get implemented, new formats become a result (so as not to risk breaking old, tried and true formats). As of Bazaar 1.6, a feature called "stacking" was introduced, that allowed bzr branches to only have the history specific to that branch, and just keep a reference to the trunk branch. This is great if you have LOTS of history for your project, and pushing seems to take forever. If you upgrade your branch to format 1.6 by doing bzr upgrade --format=1.6 you'll now be able to push stacked branches. If you're using the Bazaar PPA (and you really should be using it), you'll have a 1.9 format available. It's faster, supports stacking, and is awesome all around. It's not the default format, so you'll have to either create your branch with bzr init --format=1.9 or bzr upgrade --format=1.9. Import branches Distributed version control drastically reduces the barrier to entry for hacking on a project. With a VCS like CVS or Subversion, the project usually works as a meritocracy, and so you have to "prove yourself" before you get access. What if a project you really want to hack on won't give you commit access to their SVN/CVS repo? Create a project in lp, and import the the SVN or CVS branch into a bazaar branch. Then all you need do is branch from that branch, and hack on. When you're done, you diff between the current import and your branch, and send that in as a patch to the project itself. The difference is that you have a versioned copy of the making of that patch, instead of having a single checkout. Comments and suggestions are welcome. I'll do my best to keep this post up to date with new things, and once it's baked, I'll publish to a wiki somewhere. [Less]

So while I've spent my fair share of time hacking with Bazaar, I'm ashamed to say I hadn't done a lot of hacking on Bazaar. I've fixed small issues in Bazaar plugins, and even written a few of my own (although Jono Lange actually released his ... [More] implementation before I could get mine done). However, during Christmastime, I had the opportunity to hack on some Bazaar plugins that I will be releasing shortly. In this process, I learned a bunch about the bzrlib API, and its great ease of use. I thought I'd compile a bit of what I've found into a blog post or two. I'd like to start the examples off with some relatively easy exercises. In order to do some of these examples, it's best to have a local bzr branch of any kind. I'll start by demonstrating how to do some of the tasks you do from the command line (or GUI of your choice) programmatically. Getting a Branch object In order to operate on your branch, you'll need to create a Branch object. This will be a programmatic handle to your bzr branch itself. So let's start by getting the branch itself. from bzrlib.branch import Branch my_branch = Branch.open('/path/to/branch') Now we can operate on the branch with python. Let's say we want to see what config variables are set on this branch. We'll want to get the configuration of the branch, and then examine its contents. In this example, we'll check the username you'll be committing to bzr with (because you hopefully ran bzr whoami. my_branch_config = my_branch.get_config() print my_branch_config.username() Simple local branching Let's say you want to programatically create a local copy of a remote branch. from bzrlib.branch import Branch remote_branch_url = 'bzr ssh://bzr.eventuallyanyway.com/code/foo-bar-baz' remote_branch = Branch.open(remote_branch_url) local_branch = remote_branch.bzrdir.sprout( '/code/foo-bar-baz').open_branch() Getting a diff Programmatically, I think the best use for understanding the Bazaar API is to diff the changes in your current working tree. You'll do this by creating a WorkingTree object and operating on it. from bzrlib.workingtree import WorkingTree tree = WorkingTree.open('/code/foo-bar-baz') Now you've got a working tree. Let's get a diff between it's current state and its last committed state. If it's changed, commit the changes with a commit message of "Committed changes" delta = tree.changes_from(tree.basis_tree()) if delta.has_changes: tree.commit('Committed changes') All in all, I think the greatest strength of Bazaar is its easy extensibility, and easy entry into working with its API is proof. [Less]

I just finished reading Perl Testing: A Developer’s Notebook by Ian Langworth and chromatic (yes, one of the authors identifies himself/herself as “chromatic,” presumably for privacy concerns). All in all, the book was eye opening in understanding the world of testing in Perl. I develop Perl code at work in a culture that does not […]

I just finished reading Perl Testing: A Developer’s Notebook by Ian Langworth and chromatic (yes, one of the authors identifies himself/herself as “chromatic,” presumably for privacy concerns). All in all, the book was eye opening in understanding the world of testing in Perl. I develop Perl code at work in a culture that does not [...]

I just finished reading Perl Testing: A Developer’s Notebook by Ian Langworth and chromatic (yes, one of the authors identifies himself/herself as “chromatic,” presumably for privacy concerns). All in all, the book was eye opening in understanding the world of testing in Perl. I develop Perl code at work in a culture that does not […]

My AVR Dragon came today. I'm excited about it, because Atmel's AVR micro controllers have the best tool support for Linux. The Arduino has great support for Linux, and it's an AVR. However, the AVR Dragon has way more features, and more new things to mess around with. I just thought I'd share...