I am generally a big fan of Julien’s work and I’m very excited for the future of OpenStack Ceilometer of which he is the current PTL. However, in this case I think his views are understandably biased towards review workflows on very large projects like OpenStack, and I found the length of the rant slightly disproportionate to the actual substance of the points made within it. Somewhat ironically, AFAICS his blog’s own review process could use some improvement due to comments currently being disabled So here are my thoughts.
Disclaimer: currently I use GitHub for reviews more regularly than Gerrit, so my views are likely to be biased at least as much as Julien’s, but in the opposite direction
UPDATE 26/02/2013: Daniel has replied to this post, and I have replied to his reply.
As George Santayana famously said, “those who cannot remember the past are condemned to repeat it”. In light of recent news regarding music notation software, I would add with some disappointment and frustration that those who choose to ignore the past are also condemned to repeat it.
For those of you who don’t already know, Sibelius is a proprietary software product for music notation which has for many years been one of the most popular choices for professional musicians and composers. For many of the more experienced customers in the technology industry who have already been burned in the past, a heavy reliance on a single technology is enough to trigger alarm bells – what if the company providing that technology goes bust, or decides to change direction and cease work on it, or simply does an awful job (*cough* Microsoft *cough*) of maintaining and supporting that technology? Then you’re up a certain creek without the proverbial paddle.
In the IT industry, this is a well-known phenomenon called vendor lock-in. A powerful movement based on Free Software was born in the early eighties to free computer users from this lock-in, and is now used on billions of devices world-wide. You may have never heard of Free Software, but if you own an Android phone or a “broadband” router, or have ever used the Firefox browser or Google Chrome, you have already used it. The vast majority of the largest companies in the world all run Free Software in their datacentres around the world; for example, every time you access Google or Facebook you are (indirectly) using Free Software.
In the summer of 2011, I quit my job to resume full-time music studies. During the summer semester at the Berkeley Jazzschool in California, I started learning John Coltrane’s solo on the title track of his famous album Blue Train. It was really tough going, but addictive – I was getting my arse handed to me on a plate on a daily basis by a dead person, but I felt like I was way off the well-trodden path and that was really satisfying!
After 3 months studying in various places in the USA, I got back home and resumed work on this transcription in earnest. It became part of my daily routine, and I craved the day that I could play the whole thing note perfect at the same speed as the original. There were so many notes to fit in that I had to come up with totally new ways to use my left thumb, on which the normal cellist’s callus grew to epic proportions. Trane became the best cello teacher I never had. Unfortunately, just around the time I was getting close to being able to nail it, real life intervened, and I had to refocus on earning money. Inspired by Benoît Sauvé’s incredible rendition of the same solo on recorder (recorder?! what a mofo – check out his other videos), I did a couple of very rough recordings with my compact camera for posterity, and moved on.
Sometime later, I discovered a John McLaughlin video on YouTube (sadly no longer available) which had an awesome animated transcription at the bottom – a really cool glimpse inside the craft of a master musician. Then it occurred to me that I could do the same kind of thing with my video, and publish it in case there are any other jazz cellists out there who would be interested in it. I put a lot of effort into notating and fingering it, so it seemed a waste to just let it rot and never see the light of day. After all, I already had the source files and a video, so it was just a simple matter of combining the two, right? How hard could it be?
Very very hard, it turns out. I had to write two new pieces of software, completely overhaul a third, and fix some obscure bugs hidden deep inside a fourth. But I didn’t discover that until I’d reached the point of no return …
I’ll probably blog more at some point about the software engineering hoops I had to jump through in order to make this all work. Email me if you’re interested.
In the mean time, hope you enjoy the video! (You can also view it on YouTube.)
In the Free and Open Source software worlds, it seems that a lot of people with good intentions don’t understand how to contribute efficiently and effectively to upstream software projects. I say this based on personal experience: I sometimes receive patches to projects I maintain, where despite good intentions and a perfectly valid goal (e.g. a bug-fix or feature implementation), the patches are fundamentally flawed in a variety of ways. So unfortunately I cannot accept them without negatively impacting the quality or maintainability of the project. And I don’t even maintain any wildly popular projects.
It is possible to spend a lot of money on training to learn how to avoid these mistakes, and also many well-organized projects already provide good documentation on how to contribute, such as the Linux kernel and git. However, these documents typically mix up generic advice with project-specific advice. In this post I would like to present a list of generic advice on how to write patches which have the maximum chance of being accepted quickly and with gratitude rather than resentment!
Yesterday I did an online upgrade of my laptop from openSUSE 12.1 to 12.2, using this procedure. It was almost a painless process; however unfortunately something crashed the whole X session part-way through the upgrade so I had to manually re-run zypper dup from a virtual console to complete it. The procedure should probably warn about that scenario in some way, although there is no obvious clean solution, e.g. switching to runlevel 3 before starting the upgrade would probably kill the network when NetworkManager is in use. I also had some weirdness related to my encrypted /home partition (despite the advice in the release notes).
The final issue was Google Chrome failing to start with the following error:
/usr/bin/google-chrome: error while loading shared libraries: libbz2.so.1.0: cannot open shared object file: No such file or directory
It seems that this is at least in part due to a disagreement between Google engineers and Linux distros on what symlinks ldconfig should generate. If you look in the %post section of the google-chrome-stable rpm, you’ll see
# Most RPM distros do not provide libbz2.so.1.0, i.e.
# https://bugzilla.redhat.com/show_bug.cgi?id=461863
# so we create a symlink and point it to libbz2.so.1.
# This is technically wrong, but it'll work since we do
# not anticipate a new version of bzip2 with a different
# minor version number anytime soon.
I don’t have time to decipher openSUSE’s shared library packaging policy, but I assume it’s deliberate that /usr/lib64/libbz2.so.1.0 does not exist as a symlink even though /usr/lib64/libbz2.so and /usr/lib64/libbz2.so.1 do.
It has been suggested to me that this omission could be related to http://en.opensuse.org/openSUSE:Usr_merge. Regardless, google’s hack should have compensated for this, but for some reason (presumably related to the upgrade), there was a dangling symlink in /opt/google/chrome:
This symlink is not owned by any rpm, which suggests that google’s hack might be in violation of the FHS for modifying a static and potentially read-only filesystem – although that’s moot since the modification would only happen at install-time at which point opt has to be mounted read-write anyway. Regardless, removing that dangling symlink and pointing it to /usr/lib64/libbz2.so.1 fixed the issue.
RSS for: 
Comments (1) 
Themocracy