notes from Ubuntu Down Under
I'm at the Ubuntu Down Under conference at the Vibe Hotel in Rushcutter's Bay, Sydney. We're here through to Saturday 2005-04-30, feel free to drop by if you're around.
This idea of open company conferences is very 21st-century: here we are having a major company meeting, open to the open source community, our users, partners, etc.
The schedule is full of "BOF Sessions", where people talk about various issues, mostly setting the requirements and high-level designs for what we will build over the next year. (And I mean full: the programme, which is mandatory for employees, runs from 9am to after 8pm.) After each session, one or two people are required to write it up into a "spec" on the wiki, such as the one called GrumpyGroundhog. These specs get reviewed by various people, including professional technical editors.
This has several very interesting consequences.
Requiring people to write down notes after the session avoids having really interesting conversations and then forgetting about them, or forgetting some of the details.
Getting reasonably polished documentation out the end helps keep people who couldn't get to the conference in the loop.
Getting developers involved in developing the requirements for different parts of the business brings a remarkable advance in signup and understanding of the whole business context.
posted Thu 28 Apr 2005 in /conf/udu | link
Andrew Morton's keynote
Andrew's talk at lca was interesting, as ever. (I think he reads from a prepared text, which makes it a bit dry, but the text was good.)
One point is that every person who posts a patch to an open source project represents a person who not only has a problem, but cared enough to spend time attempting a fix. Andrew says every patch deserves at least some kind of response, and perhaps to be merged even if it's not the perfect fix. He takes the opposite position to Linus, who says his job is mostly to say no.
Development without a shared CVS server — whether by patches-over-mail or a distributed VCS — runs the risk of being too tough on people who want to put fixes in. I think I've made that mistake in the past.
posted Tue 26 Apr 2005 in /software/opensource | link
Impatience
From a history of Windows NT:
The first two weeks of development were fairly uneventful, with the NT team using Microsoft Word to create the original design documentation... Finally, it was time to start writing some code.
(I wish I'd seen this line a couple of days ago and could have quoted it in my bzr talk; I spent at least six full weeks writing and reviwing design documentation for that. :-)
posted Fri 22 Apr 2005 in /software | link
Bugzilla and Bazaar-NG
I was talking to Luis Villa at LCA and had an idea of an interesting application for the kind of distributed version control enabled by bzr.
Essentially every Bugzilla installation is a fork of the project: people install it once, tend to customize it to fit their own use, and only intermittently install updates from the maintainers. In a previous job, I was assigned the task of removing all references to "bugs" from the installation, on the grounds that our product only had "issues", not "bugs". I understand Bugzilla is now getting to be more parameterized but there is still some customization and in any case the customization needs to be merged with the new upstream defaults.
If bugzilla was distributed with a small amount of bzr metadata it might be much easier for people to either integrate their changes into new releases, or to submit improvements for upstream integration.
I stepped in to do a talk on bzr when another speaker dropped out. It was received pretty well, and sparked a lot of interesting conversations.
posted Fri 22 Apr 2005 in /software/vc/bzr | link
galah breakfast
posted Fri 15 Apr 2005 in /photo | link
Patch queues in bzr
The response to bazaar-ng so far has been very positive. Many people are contributing bugs to fix platform problems or to add features they urgently want. It's a very pleasant experience.
One consequence is that, as for many other projects, there are patches submitted that I haven't tested and merged yet. One thing to do would be to put them in an issue tracking system of some kind, but not every project wants that. So I was thinking about what bzr can do to help within this source management problem.
Very shortly we plan to allow submission of changesets by email, as regular diffs with extra annotations. When those come in, they can be stored in a directory on my laptop or on the webserver. Because the changesets have universally unique IDs and descriptive metadata we can then ask interesting questions about the patches:
- Which ones have now been merged into the mainline, and can be deleted from the "pending" queue?
- Which ones still apply to the head of the mainline? Which of those pass all the regression tests? These might be the easiest ones to merge -- though I still have the option of merging one that isn't a perfect fit and fixing it up myself.
- What is the dependency graph between them? Maybe one patch supersedes or updates another, or depends on some infrastructure work.
This queue could be filled by a robot that looks for patches on a mailing list, or in the public trees of past contributors. Although I call it a queue it's not necessarily a FIFO queue; the integrator (me) can pull things out in whatever order. As well as the branches that are normally captured by scm systems, bazaar-ng also helps you manage a bag of patches that don't necessarily fit together yet.
In general: human integrators have a valuable role but a tool can help make them more productive.
You can imagine extending this towards something like Rusty's trivial patch monkey, or perhaps towards filtering out security critical patches as candidates for merging into a stable series.
posted Fri 15 Apr 2005 in /software/vc/bzr | link
No more bitkeeper for kernel developers
The KernelTrap story seems to pretty much just print a Bitmover press release. I suppose the other side(s) of the story will come out soon.
Much of what I would say about it is already said by other people in the kerneltrap or slashdot comments. In particular This comment is spot on:
If BitMover stated up front that all licenses would be withdrawn from all Linux developers in the event that any single Linux developer tried to reverse engineer BitKeeper, then Linus was a total idiot for agreeing to that license.
If BitMover did not state those conditions up front, then they are being evil and manipulative in yanking licenses from unrelated parties in a fit of pique over what one person is doing in his own time.
To head off any FUD at the pass: there is copious documentation of where the bazaar-ng design ideas came from. Almost all are from places other than bitkeeper; where bitkeeper has had an influence it is through things people have said about it e.g. in the kernel BK usage docs.
I have heard from some kernel maintainers that even before this they weren't using bk except to sync from Linus.
I'd really like bazaar-ng to be a great kernel development system, and I think the performance will be good, but it's going to take a while to get enough features in place for even early adopters, maybe 2-3 months.
I suspect Larry understands that if he cut them off in 2006, no one would care so much, because the open systems would be good enough. Perhaps that's why it's been done now.
It's a great demonstration of the risks of putting critical data in a system whose licence can be revoked at any time.
I was rather amused by Larry's notion that it's unacceptable for a platform vendor to compete with their application vendors. Microsoft or Apple would never do that, oh no.
The fact is that any successful product is going to attract competition. It's a predictable outcome of a free market, and not any kind of moral failing of the open source community. There is no point whining about it.
If you've been left out in the cold by Bitkeeper I encourage you to check out bazaar-ng.
posted Thu 7 Apr 2005 in /software/vc | link
file renames in bazaar-ng
Renames are completely(?) working in bzr now, after the last couple of days work. There are two commands: move moves one or more files into a different directory, and rename renames a file (and optionally also moves it.)
(I think this is one case where the unix unification of both these things into mv really causes much more trouble than it's worth.)
There is also a renames command that shows which files have moved relative to the last revision.
Demo:
demo% ls -a ./ ../ demo% bzr init demo% echo hello > one demo% bzr rename one two bzr: error: can't rename: old name 'one' is not versioned demo% bzr add one demo% bzr rename oen two bzr: error: can't rename: old working file 'oen' does not exist demo% bzr rename one two one => two demo% bzr status A two demo% bzr commit -m 'add file' demo% bzr rename two three two => three demo% bzr status R two => three demo% bzr renames two => three demo% bzr commit -m 'renamed' demo% mkdir subdir subdir/d2 demo% bzr add subdir subdir/d2 demo% bzr status A subdir/ A subdir/d2/ demo% bzr move three subdir/d2/ three => subdir/d2/three demo% cd subdir/d2 d2% bzr rename three ../four subdir/d2/three => subdir/four d2% bzr renames three => subdir/four d2% bzr status A subdir/ A subdir/d2/ R three => subdir/four d2% cd ../../ demo% bzr status A subdir/ A subdir/d2/ R three => subdir/four
The code is not published yet; it'll be up later this week.
posted Wed 6 Apr 2005 in /software/vc/bzr | link
bzr tutorial in Japanese
Tez Kamihara translated the bzr tutorial/mockup into Japanese
posted Mon 4 Apr 2005 in /software/vc/bzr | link
"Balance"
Respectful of Otters has an interesting bit on "the faux 'journalistic objectivity' achieved by presenting every story as if it had two equal sides".
Holocaust deniers intentionally blur the distinction between the First Amendment right to speak freely, without government restraint, and the right to publicity, an audience, and scholarly consideration. Unfortunately, both in the media and in academia, far too many people have been taken in by these tactics. However repellent the ideas of Holocaust deniers, they argue, it would stifle intellectual freedom and journalistic objectivity to... well, apparently, to insist that the truth be presented as the truth.
It seems to me that Wikipedia's philosophical agonizing about the neutral point of view comes closer to tackling this than any other discussion I have seen. (Perhaps a similar or better theory is developed in journalism classrooms or newsrooms, but we don't see the discussion and rarely see good results.)
posted Sun 3 Apr 2005 in /software/wikipedia | link
Tasteful and attractive composites
Havoc wrote something that describes very well how I am trying to run bazaar-ng:
One of the more annoying properties of the Internet is that no matter what you post to your blog (or mailing list, or chat) people add comments like: "that isn't new, the Amiga had it in 1987" or "that isn't new, we did that with punch cards in 1953" or "Longhorn has that already" or whatever. These comments are especially popular in places like osnews and slashdot.
I usually add a disclaimer to my posts specifically to head this off, but it never helps. (Shocking!)
Why post ideas? It's not to get credit for originality. It's because in this specific context, at this specific time, we should discuss and possibly implement those ideas.
Side point: there's much to be gained by simply doing something better than it's been done in the past. Apple's new Pages app, maps.google.com, there are countless examples. They aren't really "new ideas" per se, they are well-done and tasteful composites of many old ideas. And they were finished, and made available. Not a trivial thing in the modern software industry.
Some people say there is nothing really new in bzr but they like it anyhow; to me that counts as success.
posted Sat 2 Apr 2005 in /software/vc/bzr | link
Rocking the Bazaar
bzr is really coming along very well.
I have stepped up to give a seminar about it at linux.conf.au in place of a speaker who had to pull out. I didn't originally submit an abstract because I thought it wouldn't be sufficiently ready to talk about, but as it turns out it is.
If I can get remote operation working before the conference I'd like to put these commands in the abstract in the online program:
bzr get http://bazaar-ng.org/bzr/sandbox cd sandbox vi hello.txt bzr send
One really important use case for a version control system is that of being told how to do basic operations by someone else. This is the first encounter most people have: wanting to try something out in the development head of some project kept in CVS. It's very important that this be as simple as possible, and that it work reliably. Doubly so because the person will typically not get their instructions from the program's manual, but rather second hand from whatever person or web page is helping them get started on that particular project.
Development has gone well in the last week or so: there is now a rudimentary mv command, a nice ignored that shows what is ignored and why.
Daylight saving finished in Australia, which correctly tested that bzr records dates as GMT + timezone, somewhat like email:
.... ---------------------------------------- revno: 100 committer: mbp@sourcefrog.net timestamp: Sun 2005-03-27 00:41:53 +1100 message: - add test case for ignore files ---------------------------------------- revno: 101 committer: mbp@sourcefrog.net timestamp: Sun 2005-03-27 19:14:45 +1000 message: change default ignore list
jdub loves the info command, saying he'd run it all the time to see the numbers ticking over.
mbp@hope% bzr info
branch format: Bazaar-NG branch, format 0.0.4
in the working tree:
101 unchanged
0 modified
0 added
0 removed
0 renamed
2 unknown
262 ignored
4 versioned subdirectories
branch history:
161 revisions
2 committers
23 days old
first revision: Wed 2005-03-09 04:08:15 +0000
latest revision: Fri 2005-04-01 18:27:01 +1000
text store:
330 file texts
2392 kB
revision store:
161 revisions
55 kB
inventory store:
161 inventories
3219 kB
posted Fri 1 Apr 2005 in /software/vc/bzr | link
Archives 2008: Apr Feb 2007: Jul May Feb Jan 2006: Dec Nov Oct Sep Aug Jul Jun Jan 2005: Sep Aug Jul Jun May Apr Mar Feb Jan 2004: Dec Nov Oct Sep Aug Jul Jun May Apr Mar Feb Jan 2003: Dec Nov Oct Sep Aug Jul Jun May
Copyright (C) 1999-2007 Martin Pool.