Entertainer Media Center

What!? I have a blog!? I guess I should say something.🙂 I recently worked on improving the translations workflow for Entertainer, and hopefully this work will help make Entertainer rock for i18n (which is short for internationalization in the global community because the word is very long, 18 letters long, to be exact). In the […]

What!? I have a blog!? I guess I should say something. I recently worked on improving the translations workflow for Entertainer, and hopefully this work will help make Entertainer rock for i18n (which is short for internationalization in the global community because the word is very long, 18 letters long, to be exact). In the […]

What!? I have a blog!? I guess I should say something. 🙂 I recently worked on improving the translations workflow for Entertainer, and hopefully this work will help make Entertainer rock for i18n (which is short for internationalization in the global community because the word is very long, 18 letters long, to be exact). In […]

What!? I have a blog!? I guess I should say something. 🙂 I recently worked on improving the translations workflow for Entertainer, and hopefully this work will help make Entertainer rock for i18n (which is short for internationalization in the global community because the word is very long, 18 letters long, to be exact). In […]

What!? I have a blog!? I guess I should say something. I recently worked on improving the translations workflow for Entertainer, and hopefully this work will help make Entertainer rock for i18n (which is short for internationalization in the global community because the word is very long, 18 letters long, to be exact). In the [...]

I did a presentation today at Warwick University titled “Open Source Development on the Entertainer Media Center”. It went well and there were plenty of questions about the project afterwards. The presentation was created in OpenOffice and you can download the file here [3069kb].

I haven't been able to work on Entertainer for a long time now. It's a shame, because I really like the project and think that it has potential. Especially, because of the great develoment team it has gathered. About a year ago, I purchased domain ... [More] entertainer-project.com that was used as a home of the project. This still applies, but I gave up the domain and it is now owned by Paul Hummer, our most dedicated Entertainer developer. read more [Less]

I've moved this site over to its new home. If you're seeing this message (and links to allow comments), you're on the right server. I'll be shutting down the old system at the end of the week. A side effect, however, was that I seemed to have spammed the various planets that my blog is attached to. Sorry for the noise. ! :)

I use bzr everyday. Seriously, every day. It's become a tool that I honestly can't live without, and, while I'm not really a "fanboy" per se, I feel let down whenever I need to use another VCS. One of the greatest things about bzr is its ... [More] ability to have plugins. People talk about how many "commands" other VCSes use, but they aren't plugins, so they are limited to what can be done. I think there's a real value in being able to use an established API to work with repositories, trees, and branches. Because I use bzr frequently, I've come to love a few plugins that I can no longer live without, which I've compiled for your reading pleasure. Bzrtools Aaron Bentley compiled a set of various tools and made bzrtools. If you're using the bzr PPA, chances are that bzrtools gets upgraded with bzr. It took me a while before I realized that tools like shelve, cbranch, and patch were from bzrtools. shelve allows you to take a specific change and "put it on the shelf" for a bit. For instance, say that you find a bug while working on a feature. You can shelve the changes for your feature. This will allow you to specify what goes on the shelf. If you shelve it all, the tree will look like you did no work at all. Then you can fix your bug and commit, and then unshelve your changes using unshelve. To see what's on the shelf, use shelf. cbranch is a feature I don't think many will use, but those who will use it will soon learn they can't live without it. I like to keep my trees and and my branches/repositories separate. I keep the branches in a repo, and then do lightweight checkouts into an area where I can work. cbranch will, in one fell swoop, branch from a location into my shared repository, and then create a lightweight checkout in the place where I do my work. THAT is the very definition of efficiency. bzrtools provides all sorts of other commands, such as pushing over rsync (rspush), pulling of many branches at once (multi-pull), importing from a tarball (import), and the ability to kill unknown files in a working tree (clean-tree). bzr-loom bzr-loom is the bazaar version of quilt, mercurial-queues, etc. The basic idea is that you have a few branches that are all built on top of each other, but are separate in versioning. Start with one "thread," work on it. Create another thread that is dependent on the first, work on it. Create another thread, but find a bug in the implementation of the first thread's feature, so go down to that thread and fix the bug, and move back up. I think my best use case is when dealing with reviews. No one really wants to get a 15K line patch for the next big feature of an application. I use threads in a loom in this situation. I can work on the first thread, and submit that for review. I can then create another thread, hack on it, and submit it for review. If, during the review of the first branch, I can easily hop down to that thread, fix changes, and those changes will be available in all the upper threads. This allows me to concurrently work on a branch, so I'm not blocked on reviews because someone hasn't gotten around to actually reviewing them yet (which I am guilty of doing). The great thing about this is, if I can land the first branch after review, and it won't break trunk. I can land that branch, and continue on. When that branch lands, I just combine-thread and keeping hacking on the upper threads. It's even more flexibility in an already Agile system. bzr-upload bzr-upload is just a small plugin, but it's infinitely better than the alternative. bzr-upload allows you to sftp a branch's working tree to a system that doesn't have bzr installed. This was especially helpful when I was on a shared server account. The great thing is that I can easily push a version of the working tree that's not the current revision. So, if I had bzr uploaded a bad version of something, I could revert easily with a bzr upload of a previous revision. Bazaar External Merge I've liked meld since the beginning of my days using mercurial. When I first was using it, I was manually syncing a Mercurial repo to an svn clone (before there were good tools). bzr ext-merge allows me to bring meld in when I need to get my eyes on the diff itself to figure out how to resolve conflicts. I don't use this tool a lot, but it's still one I couldn't live without, because when I need it, I really need it. Bzr Gtk Once again, a plugin I don't use every day, but would be upset if I didn't have it. Out of the various options, I find I use bzr viz the most, to view the history of the branch. It can be rather slow in cases where the branch is large, but the visualization of branch data is great. I can see just how the merges came together in various branches, etc. I also find that every once in a while, I use bzr gannotate to see the visual annotations of a given file. Being able to visualize that data is helpful in that I can see who modified what, and when they did it. This isn't a particularly stellar feature, but it's one that would make life hard to be without. Of notable mention of other cool bzr plugins (but those that I don't really need per se) are: bzr-diffstat, bzr-builddeb, bzr-vimdiff, and bzr-svn. [Less]