I arrived in Prague yesterday for the Ubuntu Developer Summit. Including time spent in transit in Singapore and London, the flights took about 30 hours.
As I was flying on BA, I got to experience Heathrow Terminal 5. It wasn’t quite as bad as some of the horror stories I’d heard. There were definitely aspects that weren’t forgiving of mistakes. For example, when taking the train to the “B” section there was a sign saying that if you accidentally got on the train when you shouldn’t have it would take 40 minutes to get back to the “A” section.
It is also quite difficult to find water fountains in the terminal, which is inexcusable given that they don’t let people bring their own water bottles.
I had been a bit worried that they’d lose my bag, but it arrived okay in Prague. Jonathan was not so lucky.
As well as the Ubuntu and Canonical folks, there are a bunch of Gnome developers here, including Ryan, Murray, Olav, David and Lennart. It will be an interesting week.
One of the features I recently discovered in Bazaar is the --author option for “bzr commit“. This lets you make commits to a Bazaar branch on behalf of another person. When used, the new revision credits two people: you as the committer and the other person as the author.
While Bazaar does make it easy for non-core contributors to send changes in a form that correctly attributes them (e.g. by publishing a branch or sending a bundle), I doubt we’ll ever see the end of pure patches. Some cases include:
- Patches based on a tarball release. In these cases the contributor likely hasn’t even used the VCS.
- People send simple diffs from e.g. “bzr diff” since that is sometimes the easiest solution (or what they do by default due to having transferred their knowledge from another VCS).
- Some people use a VCS bridge so they can work with their favourite VCS. They might not be able to provide their changes as Bazaar commits due to this.
The --author option lets you commit these changes in a way that credits the contributor for their work. The author of the change will then be displayed in “bzr annotate” output and credited along with the you in the “bzr log” output.
The feature is also used by a number of plugins such as bzr-rebase: if you replay or rebase someone else’s changes, the new revisions will creit you as the committer and the original committer as the author.
Since upgrading to Ubuntu Hardy, I’ve been enjoying using Firefox 3. The reduced memory usage has made a lot of other things nicer to use (I don’t feel like I need to buy more memory now). One thing that is nice to see fixed is caching of SSL content.
Now it was possible to turn on disk caching in Firefox 2 through the browser.cache.disk_cache_ssl hidden option, but it had a serious drawback: the security information for resources was not saved in the disk cache so you’d get a broken padlock if resources were loaded from the cache.
Firefox 3 fixes up the disk cache to record the security information though, so turning on disk_cache_ssl setting no longer results in a broken padlock. But what about all the people using Firefox with its default settings (or those who do not want all SSL content cached to disk)? For these users, the web server can still cause some content to be cached.
By sending the “Cache-Control: public” response header, the server can say that a resource can be stored in the disk cache. Firefox 3 will respect this irrespective of the disk_cache_ssl setting. This should bring Firefox back into parity with Internet Explorer with respect to network performance on SSL web sites.