Planet Bazaar

This is the second in a mostly-every-week series of posts about whats been happening in the development world of the Bazaar distributed version control system. The series is co-authored by John Arbash Meinel, one of the primary developers on Bazaar, and Elliot Murphy, Launchpad developer and compulsive conflict avoider.

Plugins

One of the nice things about Bazaar is the API, which enables new features to be added with plugins. Once a feature is polished and proves widely useful, it can move from a plugin into core bazaar. Most of the plugins are hosted/mirrored on Launchpad, and are a simple "bzr branch lp:bzr-plugin ~/.bazaar/plugins/plugin" away. For the rest, they are indexed at http://bazaar-vcs.org/BzrPlugins. Here's a quick summary of some of the plugins we are using on our laptops right now:

bookmarks: This allows me to store an alias for a branch location, so it is easier to branch/push to a common location. So I can type 'bzr get bm:work/foo' instead of 'bzr get bzr+ssh://server.example.com/dev/stuff/foo'

bzrtools: a collection of commands which provide extended functionality. Such as 'bzr cdiff' to display colored diffs and 'bzr shelve' to temporarily revert sections of changes.

difftools and extmerge: These plugins let me view differences in meld or kdiff3 (or anything that you want to configure, really), and do merges via meld.

email: Keep people informed of what you are working on by sending an email after every commit.

fastimport: This plugin allows me to import code from my friends mercurial repository and push it to launchpad.

git: this gives me read access to a local git repository

gtk: This is the Bazaar Gtk GUI, which has some nice tools like visualize and gcommit.

htmllog: Useful for generating html formatted logs for publishing on the web.

loom: Allows me to manage several "layers" of development in a single branch, and colloborate on those layers with other people.

notification: Gives a GUI popup when a pull or push completes

pqm: This formats a merge request to PQM. PQM then takes my branch, merges to main, runs tests, and commits the merge if all was well. This ensures that we always have passing tests in the main tree!

push_and_update: This updates the working tree when I push my branch to a remote server. Very useful for doing website updates.

removable: I try to keep all branches very small for easier review, so I have a lot of branches at one time. This tells me which branches have already been merged to the main tree (and thus can be removed). It can also let me know why something is not ready to be removed.

stats: Provides 'bzr stats' which gives a simple view of how many people have committed to your project and how many commits each has done.

update_mirrors: 'bzr update-mirrors' recursively scans for Bazaar branches and updates them to their latest upstream.

vimdiff: Adds the commands 'bzr vimdiff' and 'bzr gvimdiff'. Which opens vim in side-by-side mode, showing you your changes.

qbzr: Another great GUI for bzr, this one is written using Qt.


1.5rc1, 1.5 this Friday

Continuing our pattern of having time-based releases, bzr 1.5rc1 was released last Friday, and 1.5 final should be released tomorrow. Ever wonder how we churn out releases so regularly? The biggest factor enabling us to make consistent releases is our use of a Patch Queue Manager. It ensures that all of our 11,724 unit tests pass before allowing any merge into mainline. Even when lots of changes are landing, the trunk can be considered release quality. Most of the developers use the tip of mainline for their day-to-day work, which means that any changes get immediate use, rather than waiting for a release candidate.

By releasing every month, we have reduced the tendency to rush patches, trying to sneak them in before the next release. We know that there will be another release just around the corner, so we can land complex patches right after a release. For each release cycle, we have 3 weeks of "open" development, where any approved (peer reviewed) patch can be merged. Then we have a feature freeze week, where only bug fixes are supposed to be merged. At the end of the freeze week, we release RC1 and reopen mainline for development. If no regressions are found in RC1, it is tagged as final and released after one week.

The bzr-1.5 release is mostly focused on fixing small ui bugs, a couple of performance improvements, and some documentation updates.

(edit: 2008-05-16, the merged plugin changed and is now called bzr-removable)

There’s been a flurry of discussion around the idea of syncronicity in free software projects. I’d like to write up a more comprehensive view, but I’m in Prague prepping for FOSSCamp and the Ubuntu Developer Summit (can’t wait to see everyone again!) so I’ll just contribute a few thoughts and responses to some of the commentary I’ve seen so far.

Robert Knight summarized the arguments I made during a keynote at aKademy last year. I’m really delighted by the recent announcement of that the main GNOME and KDE annual developer conferences (GUADEC and aKademy) will be held at the same time, and in the same place, in 2009. This is an important step towards even better collaboration. Initiatives like FreeDesktop.org have helped tremendously in recent years, and a shared conference venue will accelerate that process of bringing the best ideas to the front across both projects. Getting all of the passionate and committed developers from both of these into the same real-space will pay dividends for both projects.

Aaron Seigo of KDE Plasma has taken a strong position against synchronized release cycles, and his three recent posts on the subject make interesting reading.

Aaron raises concerns about features being “punted” out of a release in order to stick to the release cycle. It’s absolutely true that discipline about “what gets in” is essential in order to maintain a commitment on the release front. It’s unfortunate that features don’t always happen on the schedule we hope they might. But it’s worth thinking a little bit about the importance of a specific feature versus the whole release. When a release happens on time, it builds confidence in the project, and injects a round of fresh testing, publicity, enthusiasm and of course bug reports. Code that is new gets a real kicking, and improves as a result. Free software projects are not like proprietary projects - they don’t have to ship new releases in order to get the money from new licenses and upgrades.  We can choose to slip a particular feature in order to get a new round of testing and feedback on all the code which did make it.

Some developers are passionate about specific features, others are passionate about the project as a whole. There are two specific technologies, or rather methodologies, that have hugely helped to separate those two and empower them both. They are very-good-branching VCS, and test-driven development (TDD).

We have found that the developers who are really focused on a specific feature tend to work on that feature in a branch (or collaborative set of branches), improving it “until it is done” regardless of the project release cycle. They then land the feature as a whole, usually after some review. This of course depends on having a VCS that supports branching and merging very well. You need to be able to merge from trunk continuously, so that your feature branch is always mergeable *back* to trunk. And you need to be able to merge between a number of developers all working on the same features. Of course, my oft-stated preference in VCS is Bazaar, because the developers have thought very carefully about how to support collaborative teams across platforms and projects and different workflows, but any VCS, even a centralised one, that supports good branches will do.

A comprehensive test suite, on the other hand, lets you be more open to big landings on trunk, because you know that the tests protect the functionality that people had *before* the landing. A test suite is like a force-field, protecting the integrity of code that was known to behave in a particular way yesterday, in the face of constant change. Most of the projects I’m funding now have adopted a tests-before-landings approach, where landings are trunk are handled by a robot who refuses to commit the landing unless all tests passed. You can’t argue with the robot! The beauty of this is that your trunk is “always releasable”. That’s not *entirely* true, you always want to do a little more QA before you push bits out the door, but you have the wonderful assurance that the test suite is always passing. Always.

So, branch-friendly VCS’s and test-driven development make all the difference.  Work on your feature till it’s done, then land it on the trunk during the open window. For folks who care about the release, the freeze window can be much narrower if you have great tests.

There’s a lot of discussion about the exact length of cycle that is “optimal”, with some commentary about the windows of development, freeze, QA and so on.  I think that’s a bit of a red herring, when you factor in good branching, because feature development absolutely does not stop when the trunk is frozen in preparation for a release. Those who prefer to keep committing to their branches do so, they scratch the itch that matters most to them.

I do think that cycle lengths matter, though. Aaron speculates that a 4-month cycle might be good for a web site. I agree, and we’ve converged on a 4-month planning cycle for Launchpad after a few variations on the theme. The key difference for me with a web site is that one has only one deployment point of the code in question, so you don’t have to worry as much about update and cross-version compatibility. The Launchpad team has a very cool system, where they roll out fresh code from trunk every day to a set of app servers (called “edge.launchpad.net”), and the beta testers of LP use those servers by default. Once a month, they roll out a fresh drop from tip to all the app servers, which is also when they rev the database and can introduce substantial new features. It’s tight, but it does give the project a lot of rhythm. And we plan in “sets of 4 months”, at least, we are for the next cycle. The last planning cycle was 9 months, which was just way too long.

I think the cycles-within-cycles idea is neat. Aaron talks about how 6 months is too long for quick releases, and too short to avoid having to bump features from one cycle to the next. I’ve already said that a willingness to bump a feature that is not ready is a strength and not a weakness. It would be interesting to see if the Plasma team adopted a shorter “internal” cycle, like 2 months or 3 months, and fit that into a 6 month “external” cycle, whether Aaron’s concerns were addressed.

For large projects, the fact that a year comes around every, well, year, turns out to be quite significant. You really want a cycle that divides neatly into a year, because a lot of external events are going to happen on that basis. And you want some cohesion between the parts. We used to run the Canonical sprints on a 4-month cycle (3 times a year) and the Ubuntu releases on a six month cycle (twice a year) and it was excessively complex. As soon as we all knew each other well enough not to need to meet up every 4 months, we aligned the two and it’s been much smoother ever since.

Some folks feel that distributions aren’t an important factor in choosing an upstream release cycle. And to a certain extent that’s true. There will always be a “next” release of whatever distribution you care about, and hopefully, an upstream release that misses “this” release will make it into the next one. But I think that misses the benefit of getting your work to a wider audience as fast as possible. There’s a great project management methodology called “lean”, which we’ve been working with. And it says that any time that the product of your work sits waiting for someone else to do something, is “waste”. You could have done that work later, and done something else before that generated results sooner. This is based on the amazing results seen in real-world production lines, like cars and electronics.

So while it’s certainly true that you could put out a release that misses the “wave” of distribution releases, but catches the next wave in six months time, you’re missing out on all the bug reports and patches and other opportunities for learning and improvement that would have come if you’d been on the first wave. Nothing morally wrong with that, and there may be other things that are more important for sure, but it’s worth considering, nonetheless.

Some folks have said that my interest in this is “for Canonical”, or “just for Ubuntu”. And that’s really not true. I think it’s a much more productive approach for the whole free software ecosystem, and will help us compete with the proprietary world. That’s good for everyone. And it’s not just Ubuntu that does regular 6-month releases, Fedora has adopted the same cycle, which is great because it improves the opportunities to collaborate across both distributions - we’re more likely to have the same versions of key components at any given time.

Aaron says:

Let’s assume project A depends on B, and B releases at the same time as A. That means that A is either going to be one cycle behind B in using what B provides, or will have to track B’s bleeding edge for the latter part of their cycle allowing some usage. What you really want is a staggered approach where B releases right about when A starts to work on things.

This goes completely counter to the “everyone on the same month, every 6 months” doctrine Mark preaches, of course.

I have never suggested that *everyone* should release at the same time. In fact, at Ubuntu we have converged around the idea of releasing about one month *after* our biggest predictable upstream, which happens to be GNOME. And similarly, the fact that the kernel has their own relatively predictable cycle is very useful. We don’t release Ubuntu on the same day as a kernel release that we will ship, of course, but we are able to plan and communicate meaningfully with the folks at kernel.org as to which version makes sense for us to collaborate around.

Rather than try and release the entire stack all at the same time, it makes sense to me to offset the releases based on a rough sense of dependencies.

Just to be clear, I’m not asking the projects I’ll mention below to change anything, I’m painting a picture or a scenario for the purposes of the discussion. Each project should find their own pace and scratch their itch in whatever way makes them happiest. I think there are strong itch-scratching benefits to syncronicity, however, so I’ll sketch out a scenario.

Imagine we aimed to have three waves of releases, about a month apart.

In the first wave, we’d have the kernel, toolchain, languages and system libraries, and possibly components which are performance- and security-critical. Linux, GCC, Python, Java, Apache, Tomcat… these are items which likely need the most stabilisation and testing before they ship to the innocent, and they are also pieces which need to be relatively static so that other pieces can settle down themselves. I might also include things like Gtk in there.

In the second wave, we’d have applications, the desktop environments and other utilities. AbiWord and KOffice, Gnumeric and possibly even Firefox (though some would say Firefox is a kernel and window manager so… ;-)).

And in the third wave, we’d have the distributions - Ubuntu, Fedora, Gentoo, possibly Debian, OpenSolaris. The aim would be to encourage as much collaboration and discussion around component versions in the distributions, so that they can effectively exchange information and patches and bug reports.

I’ll continue to feel strongly that there is value to projects in getting their code to a wider audience than those who will check it out of VCS-du-jour, keep it up to date and build it. And the distributions are the best way to get your code… distributed! So the fact that both Fedora and Ubuntu have converged on a rhythm bodes very well for upstreams who can take advantage of that to get wider testing, more often, earlier after their releases. I know every project will do what suits it, and I hope that projects will feel it suits them to get their code onto servers and desktops faster so that the bug fixes can come faster, too.

Stepping back from the six month view, it’s clear that there’s a slower rhythm of “enterprise”, “LTS” or “major” releases. These are the ones that people end up supporting for years and years. They are also the ones that hardware vendors want to write drivers for, more often than not. And a big problem for them is still “which version of X, kernel, libC, GCC” etc should we support? If the distributions can articulate, both to upstreams and to the rest of the ecosystem, some clear guidance in that regard then I have every reason to believe people would respond to it appropriates. I’ve talked with kernel developers who have said they would LOVE to know which kernel version is going to turn into RHEL or an Ubuntu LTS release, and ideally, they would LOVE it if those were the same versions, because it would enable them to plan their own work accordingly. So let’s do it!

Finally, in the comments on Russell Coker’s thoughtful commentary there’s a suggestion that I really like - that it’s coordinated freeze dates more than coordinated release dates that would make all the difference. Different distributions do take different views on how they integrate, test and deploy new code, and fixing the release dates suggests a reduction in the flexibility that they would have to position themselves differently. I think this is a great point. I’m primarily focused on creating a pulse in the free software community, and encouraging more collaboration. If an Ubuntu LTS release, and a Debian release, and a RHEL release, used the same major kernel version, GCC version and X version, we would be able to improve greatly ALL of their support for today’s hardware. They still wouldn’t ship on the same date, but they would all be better off than they would be going it alone. And the broader ecosystem would feel that an investment in code targeting those key versions would be justified much more easily.

A while back I posted about how to set up a new launchpad project. At the time it took quite a few steps to set everything up that you wanted. I'm happy to report that a lot of those steps have been streamlined, so I posting a new step-by-step instruction for setting up your project in Launchpad.

1. Make sure the project isn't already registered. A lot of upstream projects have already been registered in Launchpad, as it is used to track issues in Ubuntu. So it is always good to start on the main page and use the search box "Is your project registered yet?".
2. If you don't find your project, there will be a link to Register a new project
3. The form for filling out your project details has been updated a bit, but you should know the answers. (I still use 'bazaar' as the "part of" super-project, and bzr-plugin-name for my plugins)
4. This is where things start to get easier. After you have registered the project you can follow the Change Details link. This is generally https://launchpad.net/PROJECT/+edit. It was the same before, but now more information is on a single page, so you can set up more at once. Here I always set the bug tracker to be Launchpad, I click the boxes to opt-in for extra launchpad features.
5. Optionally you can assign the project to a shared group. Follow the "Change Maintainer" link (https://launchpad.net/PROJECT/+reassign). I generally assign them to the bzr group, because I don't want to be the only one who can update information.
6. At this point you should be able to push up a branch to be used as the mainline using:
   bzr push lp:///~GROUP/PROJECT/BRANCH
   in my example, this is lp:///~bzr/PROJECT/trunk. (You may need to run 'bzr launchpad-login' so that bzr knows who to connect as, rather than using anonymous http:// urls)
7. You now want to associate your mainline branch with the project, so that people can use the nice lp:///PROJECT urls. You can follow the link on your project page for the "trunk" release series (usually this is https://launchpad.net/PROJECT/trunk) On that page is a "Edit Source" link, or https://launchpad.net/PROJECT/trunk/+source.
   Set the official release series branch to your new ~GROUP/PROJECT/BRANCH.

See, now it is only 7 steps instead of 11. (Though only really one or two steps has actually changed.)

An update on the long term plans for Ubuntu release management. 8.04 LTS represented a very significant step forward in our release management thinking. To the best of my knowledge there has never been an “enterprise platform” release delivered exactly on schedule, to the day, in any proprietary or Linux OS. Not only did it prove that we could execute an LTS release in the standard 6-month timeframe, but it showed that we could commit to such an LTS the cycle beforehand. Kudos to the technical decision-makers, the release managers, and the whole community who aligned our efforts with that goal.

As a result, we can commit that the next LTS release of Ubuntu will be 10.04 LTS, in April 2010.

This represents one of the most extraordinary, and to me somewhat unexpected, benefits of free software to those who deploy it. Most people would assume that precise release management would depend on having total control of all the moving parts - and hence only be possible in a proprietary setting. Microsoft writes (almost) every line of code in Windows, so you would think they would be able to set, and hit, a precise target date for delivery. But in fact the reverse is true -  free software distributions or OSV’s can provide much better assurances with regard to delivery dates than proprietary OSV’s, because we can focus on the critical role of component selection, integration, testing, patch management and distribution rather than the pieces which upstream projects are better able to handle - core component feature development. This is in my mind a very compelling reason for distributions to focus on distribution - that’s the one thing they do which the upstreams don’t, so they need to invest heavily in that in order to serve as the most efficient conduit of upstream’s work.

We also committed, for the first time, to a regular set of point releases for 8.04 LTS. These will start three months after the LTS, and be repeated every six months until the next LTS is out. These point releases will include support for new hardware as well as rolling up all the updates published in that series to date. So a fresh install of a point release will work on newer hardware and will also not require a big download of additional updates.

Gerry Carr at Canonical put together this diagram which describes the release management plan very nicely:

The Ubuntu team does an amazing job of ensuring that one can update from release to release, and from LTS release to LTS release directly, too. I’m very proud to be part of this community! With the addition of some capability to support newer hardware in LTS releases, I think we are doing our part in the free software community - helping to deliver the excellent work of thousands of other teams, from kernel.org to GNOME and KDE, safely to a huge audience.

There’s one thing that could convince me to change the date of the next Ubuntu LTS: the opportunity to collaborate with the other, large distributions on a coordinated major / minor release cycle. If two out of three of Red Hat (RHEL), Novell (SLES) and Debian are willing to agree in advance on a date to the nearest month, and thereby on a combination of kernel, compiler toolchain, GNOME/KDE, X and OpenOffice versions, and agree to a six-month and 2-3 year long term cycle, then I would happily realign Ubuntu’s short and long-term cycles around that. I think the benefits of this sort of alignment to users, upstreams and the distributions themselves would be enormous. I’ll write more about this idea in due course, for now let’s just call it my dream of true free software syncronicity.

This is the first in a mostly-every-week series of posts about whats been happening in the development world of the Bazaar distributed version control system. The series is co-authored by John Arbash Meinel, one of the primary developers on Bazaar, and Elliot Murphy, Launchpad developer and wanted criminal.

We get to talk about anything we want. This week:

• What's been happening for a better GUI on Windows
• What's new in the 1.4 release
• Importing from other VCS's with bzr fast-import

... details ...

GUI on Windows

We found this guy named Mark Hammond who claims to know how to make python stuff work well on windows. There is an existing GUI tool for Bazaar on Windows called TortoiseBZR now, modeled after TortoiseSVN. If you haven't used a Tortoise before, they are extensions that integrate into Windows Explorer; allowing you to see and control the versioning of your files without needing to change to a separate tool.

Mark has taken a look and proposed a series of enhancements to make the tool work even better. Bazaar already works very well from the Windows command prompt, but we want to provide excellent GUI tools as well. Take a look at the TortoiseBZR web page for screenshots of it in action.

What's new in the 1.4 release

The Bazaar team releases a new version of Bazaar just about every month, with both bugfixes and new features. The bzr-1.4 release came out last Thursday, May 1st.

The major changes for 1.4 include improvements in performance of 'log' and 'status', and a new Branch hook called post-change-branch-tip, which will trigger any time a Branch is modified (push, commit, etc). This should enable server generated emails whenever somebody publishes their changes. Write something cool with it and tell us what you did!

The full list of changes for 1.4 can be found at: https://launchpad.net/bzr/1.4/1.4
The list of all changes is at http://doc.bazaar-vcs.org/bzr.dev/en/release-notes/NEWS.html

bzr fast-import

Bazaar fast-import is a plugin for bazaar that allows you to import from many different version control systems. The fast-import stuff is intended to support any system that can use the fast-export format. This format was originated by git developers, and quickly adopted elsewhere. So if a source format can generate a "fast-import" stream, you should be able
to import it into Bazaar.

• CVS
  To convert from cvs, you currently use the cvs2svn converter. Which has a flag to generate a "fast-import" stream.
• Mercurial
  There is a script called hg-fast-export.py bundled with the plugin (in the exporters/ directory).
• SVN
  The svn-fast-export script is also bundled with the bzr-fastimport plugin.
• git
  Bundled with the standard git distribution is the git-fast-export command.
• Your own exotic system here.

Give fast-import a try. It's mostly designed for 1-time conversions, rather than mirroring, but there are already some rudimentary mirroring capabilities.


That's all for the first installment of "This Week in Bazaar".

(edited for formatting)

Javier Derderian is working on ">">"integrating Bazaar into gedit, the GNOME standard text editor, so that you can very easily record changes, push them to a server, and so on. Bazaar's model that a branch is just a directory with extra metadata fits pretty well here. He just made another exciting release (or should that be "excited"? :-)

• Suicide in Japan
• Too soon to relax
• A lot to be angry about
• Fearful asymmetry
• Death be not proud
• Unsteady as she goes
• Speedy decline
• The Montana Meth Project
• Prove who you are
• Cristina in the land of make-believe
• Unfraternal
• Right back
• Hopes of healing
• Oceans apart
• Rank injustice
• Look behind you

Now I want to hear what A lot to be angry about sounds like.

Morten asked today on irc about an error I have hit before myself: you go to upload your new package to a PPA, and get an odd message of Not permitted to upload to the RELEASE pocket in a series in the 'CURRENT' state.

What this means is that your upload was trying to go into the Ubuntu distribution, rather than into a PPA, and you're not authorized to put it there. The underlying reason is that the command line for dput, the tool for uploading source packages, is

dput [options] [host] package.changes ...

It's easy to forget the optional host parameter and if it's omitted it uploads into the Ubuntu archive.

There is a pretty easy (if crude) way to disable this behaviour, by adding these lines to your ~/.dput.cf:

[DEFAULT]
default_host_main = notspecified

[notspecified]
fqdn = SPECIFY.A.PPA.NAME

The 1.4 release of Bazaar includes handy improvements to the speed of log and status, new options for several commands, improved documentation, and better hooks, including initial code for server-side hooks. A number of bugs have been fixed, particularly in interoperability between different formats or different releases of Bazaar over there network. There’s been substantial internal work in both the repository and network code to enable new features and faster performance.

You can check out the full changelog at: https://launchpad.net/bzr/1.4/1.4/
And download it at the usual location: http://bazaar-vcs.org/Download

I’ve just kicked off a wiki page to follow up on the state of Integration into IDEs, so, if you want a specific IDE worked on, or are currently working on an integration, please feel free (or encouraged even) to add it to the wiki page: http://bazaar-vcs.org/IDEIntegration

I hope that page eventually harbours enough information for any random person to land on it and find out if their favourite IDE currently works with bazaar, or enough information to start working on one.

My relationship with git is still one of love and hate. It cuts corners to increase performance in a couple of places and that can be really bloody annoying.

For example, jerry renamed one of the top-level directories in Samba 3 (revision 9f672c26d63955f613088489c6efbdc08b5b2d14). Git will skip rename detection in this revision because of the number of files it affects, thus causing the output of "git log <path>" of this particular directory to be useless.

I'm the first to admit "bzr log" on directories and files in large history projects is painfully slow, but at least it gets the output right.

cp: Brandi Carlile - The Story

It's been a busy two weeks. Wilco and I drove up to Göttingen on Sunday two weeks ago to spend some days hacking and meeting up with the other developers before the start of SambaXP. It was really nice to see everybody again after more than 7 months.

SambaXP was a bit different this year. There were three tracks during the second part of the conference this year, one more than previously and of course, there were several engineers from Microsoft attending this time! Some of the interesting talks this year included Julien's update on OpenChange, Tridge's talk on PFIF, the talk from the likewise folks and of course the talk from Microsofts' Wolfgang Grieskamp on SMB2. We also had some other informal discussions with the Microsoft folks about specific topics - very useful!

There are some photos up on the SambaXP homepage. And just to be ahead of the comments: yes, I know I need a haircut.

I did some initial work on several bits and pieces of code that I hope to expand over the next few months. Volker has started working on ncacn_ip_tcp support and I have been working on making the Samba 3 DCE/RPC library compatible with Samba 4. This should allow OpenChange to use Samba 3 in the future.

Guenther, Wilco and I made some initial progress on the policy library, allowing client-side manipulation of (group) policies in Samba. I worked with Simo on trying to get rid of an evil hack in Samba4's event subsystem.

David Holder blogged about some of the IPv6 development that we did during the conference: http://www.ipv6consultancy.com/ipv6blog/?p=34

And lots of other things I can't remember at the moment...

After the conference Andrew, Wilco and I drove back to the Netherlands and I played tour guide for a bit showing Andrew around the country during the afternoon and hacking Samba together in the morning. Later this week we took the train to Brussels, Eurostar to London and visited Sam's company
in the UK Midlands for a couple of days.

And in the midst of all this, it seems Ubuntu Hardy was released. Congratulations to all those involved!

cp: Brandi Carlile - Turpentine

Hearty congratulations to the entire Ubuntu community on the successful launch of 8.04 LTS. This was our best release cycle ever, from the planning at UDS-Boston last year, at which we had many different teams and companies, to the beta process which attracted so much in the way of testing and patches. I think we can be justifiably proud of the quality of 8.04 LTS. From the code to the documentation, from translations to advocacy, this has been a team effort with the shared goal of delivering the very best free software experience to the very widest possible audience. May Hardy be both enduring and endearing.

I’m very conscious of the fact that Ubuntu is the pointy edge of a very large wedge - we are the conduit, but we exist only because of the extraordinary dedication and effort of thousands of other communities and projects. We all owe a great deal to the team who make Debian’s “unstable” repository possible, and of course to the upstream projects from GNOME and KDE through to the Linux kernel. We hope you will be proud of the condition in which we have carried your excellent work through to the users of Ubuntu.

So, well done everybody! I hope that friends, family, colleagues and others will have the opportunity to try it out and understand why we have all devoted so much to this project. Our work is deeply important - we are helping to bring free software to a new level of acceptance and adoption in the wider world.  Ubuntu’s success adds to the success of free software. So as much as it is fun, challenging, the opportunity of a lifetime, a profession for some and a passion for others, it’s also changing the world. I don’t exactly want to shout “Save the Cheerleader, Save the World” but to me you are all Heroes.

Mark

About a year and a half ago I switched to using a Dvorak keyboard layout everywhere rather than the more common Qwerty, as one of several measures to avoid keyboard-related wrist pain. After blogging about how I was going to switch I said no more about it, partly because ironically enough my typing speed temporarily decreased quite substantially. Marius asked me what happened.

I did stick with Dvorak and I'm glad I switched. I would recommend it to anyone who uses a computer for a substantial amount of time.

It really does seem to require less stretching and remarkably less hand movement. However it may be that part of this effect is just improving touch typing, being more aware of what finger is used for what key — in other words if one somehow forgot Qwerty and then sytematically re-learned it, it might give some of these benefits.

If you do want to switch, I'd recommend just jumping in: don't try to cut over gradually, don't put stickers on your keyboard, don't rearrange the keycaps. I put a printout of the layout near my screen and just kept looking when I got lost until I'd memorized it. At the peak of switching I would type sentences in my mind in idle moments.

Command keys, and vim in particular take a bit of adaption. I found it best to just use mouse actions instead for a while, and then slow down and think about the letter of the key before pressing it. Once I'd adapted it generally worked well. I used to use emacs a lot and rarely do so now, and going back to it is very difficult because what I do remember is in muscle memory.

Passwords can be very difficult, as people tend to remember commonly-used ones by muscle memory rather than as characters. It may be wise to write them down somewhere safe, at least for the transition period.

I can't really touch-type Qwerty now: I don't hunt-and-peck but I do need to look at the keyboard when I rarely have to use it — hotel computers, boot loaders, other people's computers and so on. On the other hand I have no trouble using a Qwerty layout on my phone, I suppose because it's a different mental context.

Some people like to pry off the keyboard caps and rearrange them to correspond to the Dvorak layout. I didn't do this, and I wouldn't recommend it, for a few reasons. I think that to learn Dvorak, you need to be able to touch-type it without looking at the keycaps, if only so that you can use it on machines where you can't (or may not) modify the hardware. Conversely, sometimes you may need to type Qwerty on your own machine, or you may want to lend it to someone who can't touch type Qwerty.

Perhaps most important, the little nubs on the (physical) F and J keys really matter to me now, and if I'd moved the keycaps they'd be in completely the wrong place. Dvorak makes the "home row" concept much more important, and my hands really feel at home with the nubs under my index fingers.

The transition is easiest on a Mac: you can easily put a little switcher on the menu bar, and even use it to display an Aussie flag rather than insisting on showing the stars and stripes. On Ubuntu it works pretty well, with a few nits: the text-mode recovery environments tend to "forget" that you wanted Dvorak during upgrades, the GNOME panel indicator likes to show the rather unhelpful labels of "USA" and "USA2" (with unpredictable meanings) and in some places like the screen-lock dialog there's no indication of which layout is active.

Vista I found generally pretty poor, as it wants to set the layout per-application not per-session. I very casually play WoW on Windows, which needs both typing of text and control through keys, and so far found it's best to leave my keyboard layout in Dvorak so I can type text in the way I'm used to, and then rebind all the keys so they have the same position: the WASD diamond comes out as <AOE.

I only later heard of the Colemak layout, which is supposed to be like Dvorak but better optimized for actual typing patterns, including those that occur in programming. It may well be; the hassle of the Dvorak transition is far enough in the past and the benefits are clear enought that I'm open to trying it. Dvorak does have the advantage that although it is used by a minority of people, it is widely available: if you borrow a random person's terminal the odds are low that it will already be in the Dvorak layout, but the odds are very good that you can easily and quickly change it. This is probably not true for Colemak (as of 2008).

More later on other RSI avoidance techniques...

My favourite thing about Bazaar is actually a tool built on top of it, Bundle Buggy, a tool for managing contributions and reviews.

When you send a patch or a Bazaar bundle to the developer mailing list, Bundle Buggy gets a copy of it, sees the proposed merge, creates a web page about it, linked back to the mail thread and to a bug number if there is one.

By catching all patches to the list it makes sure that things are not accidentally dropped. The important thing though is the getting-things-done workflow and the integration with Bazaar. Seeing a long list of mails can make it hard to decide where to begin, which is an invitation to procrastinate. BB tries to sort out patches which are ready to merge, which have been reviewed by others, which you ought to review yourself, which need other work and other states. It knows about our quasi-voting process, where we try to get at least one core contributor to review all patches, and you can do the reviews entirely over mail.

BundleBuggy is (just about?) all Aaron Bentley's work, and credits Jeremy Kerr's Patchwork tool for inspiration.

We could do a lot more here, I'm sure: a nicer review interface than just showing the diff, perhaps automatically firing off a merge if the patch is approved, telling the bug and its subscribers if we believe a fix has been merged.

malbisetti@pentaserv:~/red_teatral$ history|awk ‘{a[$2]++ } END{for(i in a){print a[i] ” ” i}}’|sort -rn|head
292 bzr
51 cd
29 tail
25 ls
24 exit
17 screen
15 su
9 vim
6 rm
6 cat

Right, I might be using bzr a bit too much… 

Windows is a very important platform, and our justifiable pride in Linux and the GNU stack shouldn’t blind us to the importance of delivering software that is widely useful. I believe in bringing free software to people in a way that is exciting and empowering to them, and one of the key ways to do that is to show them amazing free software running on their familiar platform, whether that’s Windows or the MacOS.

Firefox, for example, is an inspiring free software success story, and I’m certain that a key driver of that success is their excellent support for the Windows environment. It’s a quick download and an easy install that Just Works, after which people can actually FEEL that free software delivers an innovative and powerful browsing experience that is plainly better than the proprietary alternatives. I’ve noticed that many of the best free software projects have a good Windows story. MySQL and PostgreSQL both do. Bazaar works well too. And users love it - users that may then be willing to take a step closer to living in the GNU world entirely.

So, I was absolutely delighted with the way Agostino Russo and Evan Dandrea steered the Windows-native installer for Ubuntu into 8.04 LTS. What I think is really classy about it is the way it uses the Windows Boot Manager sensibly to offer you the Ubuntu option. If I was a Windows user who was intrigued but nervous about Linux, this would be a really great way to get a taste of it, at low risk. Being able to install and uninstall a Linux OS as if it were a Windows app is a brilliant innovation. Kudos to Agostino and Evan, and of course also to the guys who pioneered this sort of thinking (it’s been done in a number of different ways). It looks crisp, clean and very professional:

I’m a little daunted at something as new as WUBI being the very first experience that people have of Linux, free software and Ubuntu, but initial reports are positive.  I did have a question from the media that started with “it didn’t work for me but…” which makes me a wee bit nervous.

So - yesterday I suggested folks hammer on the Heron for servers, today, here’s a call for folks who have a Windows machine and would like to see WUBI in action to test it out and let the developers know if there are any last-minute gotchas. Happy hunting!