random(ideas);

Yes... we can too!

Recently I saw somewhere a link to Google Video about a very nice video: How Open Source Projects Survive Poisonous People (And You Can Too). So please, if you didn't see this go and watch it now: http://video.google.com/videoplay?docid=-4216011961522818645. It is a little bit large (~50 min) but I found some nice information from real experiences that could really help to improve our communication inside Debian. So, for the curious and impatient, it is a Google TechTalk with Ben Collins-Sussman & Brian W. Fitzpatrick, SubVersion Developers, based on their experiences they show situations that can drain Project resources and they gave valuable tips, ideas and directions on how to protect the "Attention and Focus" of the Project. It is very interesting to find a lot of factors and points that we can see from time to time on Debian. Don't get me wrong, I'm really not whining, I don't think that whining would solve any problem (except if you are a 6-month hungry child), but I would love if it could give us some momentum and maybe a starting point to leave aside some old unresolved issues, giving a chance to new ideas! Which basically means, keep working together to keep building the best Operating System. :-) (But doing that with even more fun for even more people). We can too! On a totally unrelated note: my primary MX is back for quite some time, I should report that earlier, anyway, sorry about the lack of posts, thanks for your attention and see you soon. Over.

As I'm nearing the completion of my PhD, I'm starting to write about the findings from my research. The aim of my PhD is to investigate quality improvement in free software projects. After some exploratory studies about quality in free software, I decided to focus on release management as one problematic area in which improvement is possible. My approach is to study the development process of projects and to investigate ways how these processes can be improved. The hope is that such improvements will lead to increased levels of quality in the software produced by free software projects. With regard to release management, I'm focusing especially on large and complex projects, in which hundreds of volunteers need to be coordinated during release preparations. I've been looking particularly at time based release management since my exploratory studies have shown that there is significant interest in this release management strategy. The main question of my research is how and why time based release management works for large free software projects. In my first series of postings, I will introduce the seven free software projects I have studied in depth during my research. For each project, I will briefly summarize what problems the project faced in the past, what changes they have implemented to address these problems, and what outstanding problems they still have.

Eddy Petri or wrote quite an interesting text about the shortcomings of the .deb packaging format, specially comparing it to Gentoo's ebuilds. And, basically, it all comes down to this phrase:

Why this is not possible for deb right now? Simple, we have it as a rule in the policy that the debian/rules file is a makefile. So even if one would implement a class-like model for deb packages, you'd still have the debian/rules file as a make file

Now... Is debian/rules really expected to be a makefile, or it is just customary for it to be so? Look at the very top of your rules files - you will see they (at least, almost) always start with #!/usr/bin/make -f - That means, of course, that you can omit the fact they are makefiles. While packaging/debugging, I often run -say- fakeroot debian/rules build && fakeroot debian/rules clean. That, my friend, is closer to the invocation you often use for a shell script than for a makefile. I don't know if we have tools that rely on having rules called via make (and that should be easy to correct if needed), but I really don't see it problematic at a first glance to create packages based on something different than a makefile.
Recently, I've been tempted by CDBS. I still don't fully understand its flow, and it's still mostly a dark-magic beast for me, but at least I am comfortable using it for my everyday packaging work (hey, pkg-perl group, I'll be bugging you again with my weird ideas soon ;-) ), but it surely has the advantages you quote in your message: It takes part of the complexity away. Of course, it introduces some extra bits. By using CDBS, the packaging entry level is considerably lowered - but the real understanding of properly maintaining a package becomes somewhat more difficult.
Or is it just me clinging to the comfort of having learned my way around writing debian/rules?

Eddy, while I agree that ebuilds look a lot cleaner, shorter or easier than typical debian/rules + debian/control, you should consider a few things:

• There is cdbs in Debian, which provides a lot of help in packaging “easy” packages. Note though that I don’t really like the hidden magic it does.
• ebuilds don’t have to handle architecture independent data, since Gentoo doesn’t have such packages. If Debian wouldn’t have architecture independent data, debian/rules would look easier immediately.
• Updating an easy package (i.e. one without Debian specific patches) to a new upstream usually is a no-brainer in Debian as much as in Gentoo.
• With ebuild classes, you still have to know/learn which class matches your package best, so you still need to know what each class actually does. That isn’t too different to understanding dh_* stuff, if you ask me.

So all in all, I’m quite certain that the amount of learning needed to create a correct ebuild is lower than that needed to create a Debian source package, but I don’t think that packaging for Debian is hard either. And finally, Erich is quite right that a central repository for all Debian packaging scripts would be a nice thing. However it would be quite hard to determine the right VCS to use for that. Most de-central VCSes I glanced over need manual intervention on the “server” side to include patches from local developer branches. And of course there is the problem of several packages having a non-clean upstream tarball they need to repack for each release as well as several packages having a tarball which includes more than one single upstream tarball. You would need to find a way to handle those as well.

Been trying out upstart today. It's a nice piece of code, but unfortunately it's totally useless today. Not because its concepts suck; rather, because Debian packages today ship with SysV-style initscripts, and those do not integrate well with upstart: most of the features that make upstart so interesting require you to create an event.d script, which has a totally different syntax. The Debian Developer inside me couldn't help but start to think about a way to fix this, but that seems harder than what it initially would sound like to the uninitiated. My first idea was to add some /sbin executable to upstart or one of its supporting packages, so that a SysV-style initscript could exit if that binary told it that upstart was running, before doing anything. That way, a package could ship both upstart event.d files and SysV-style initscripts during a migration period, and we could get rid of the SysV-style initscripts when and if Debian eventually decides to migrate to upstar. But when I sent that past #debian-devel, someone mentioned initng, which is yet a different init implementation. If this would work for upstart, it could also work for initng, and I don't think many packages would want to ship initscripts for three different init implementations. So scratch that. My next idea was to generate initscripts, rather than have packages ship them. The amount of common code in our initscripts is huge, anyway, and it's not as if it's all that hard to write an initscript. The things an initscript needs to do are limited, anyway: start a daemon when requested, stop it, restart it, perhaps send it a SIGHUP if or when configuration updates have been performed, and provide some useful output on all that. In most cases, that's about it. So, I thought, why not create an RFC822-style file (analogously to other files in the debian/ directory of a debian source package) containing all the metadata on an initscript, and generate the correct style of initscript out of that? That should work, I thought. So I started writing a specification, and had a look at the initscript of one of my own packages, nbd-server. Which does this at some point (nonrelevant content cut out):

i=0
while [ ! -z $ NBD_FILE[$i]  ]
do
  start-stop-daemon --start --quiet --exec /bin/nbd-server (...)
  echo -n " $ NBD_FILE[$i]  ]
  i=$(( $i + 1 ))
done

There's no way you'll be able to express that type of flexibility with an RFC822-style file containing all the metadata. So, scratch that too. I still do think generating initscripts is the right thing to do, however; the question that remains is "how". One idea I had was to use m4 in an autoconf kind of way, since autoconf allows one to mix autoconf macros with "regular" shell snippets, which would be exactly the kind of flexibility that one would need. However, that totally ignores the fact that autoconf is only able to pull this off because its output is shellscript in every case. An m4 macro that has to produce output which are not, in fact, shellscripts (such as would be the case for this project) could not do that. I think I'm kinda stuck now...

Debian used to be the cool kid among Linux distributions. Because our stuff worked much better, was easy to install and especially to upgrade. Dependencies would be automatically resolved while others were fighting dependency chaos, and our menus would have all the apps in it, where others had to fill their menus on their own. And at the same time, Debian was very flexible and could be customized to become e.g. Knoppix. Our bugtracking was great and we were openly discussing bugs and all this stuff. Many of these Debian achievements are now common among distributions. Especially among Debian-derived distributions. Debian however has become a reliable 'stable' distribution often even called 'stale', while others stand in the spotlight of innovation. Other distributions have come up with maybe more advanced bugtrackers (I'm not talking bugzilla, which IMHO is overengineered) and other tools. Technically, this isn't completely true. There are still many fields where Debian is technically leading. But our focus has recently been a lot about individual packages or components (e.g. the installer). Maybe we should try focusing more on infrastructure again. In fact, Debian still has some very good infrastructure components others might be lacking. Our QA tools (including bug counters, tracking which versions are affected by which bugs, all kinds of graphs, wotomae) are great. All our update-* commands are missing in many other distributions, also things like invoke-rc.d. We have a solid Python policy to support multiple Python versions and precompilation (judging from the SELinux policy, none of the other distributions has that yet). We're able to use dash as a minimal shell instead of bash in most places (which does make a speed and memory difference). We have Debtags. But these projects don't play a key role in Debian anymore AFAICT. Trying to start a major infrastructure thing requires a LOT of engagement, maybe too much. I'd love to see better SELinux support in Debian, but I can't do it on my own, it's just too much. And I find it very hard to find people to help me with that effort. If Enrico hadn't been pushing Debtags again and again (and with a lot of code), it would also have gone stale. Despite being IMHO something that can take Debian on top again (making it a lot easier to find appropriate software). One of the reasons why Debian is still living pretty much outside is that it would be a huge effort to get maintainers to add the corresponding Tag information to their packages and so on. I've always balked at even trying that, fortunately Enrico got some tag information added via overrides to the Packages file already. Another thing that should have been happening within Debian (but happened at Ubuntu) is 'upstart'. There have been a couple of packages dealing with new init systems, but none ever managed to get support into other packages (nor is there any package in Debian with upstart support that I'm aware of). Getting SELinux strict support into init ramdisks is another big thing I'm too scared of to even attempt... i.e. I doubt that I'll be able to do that on my own, yet even to get it into the actual packages... DPL candidates: any ideas on how to be come more agile in such points (e.g. adding support to sysvinit+upstart+initng+runit to all packages with init scripts)? It took us already ages to get LSB headers added to many init scripts. Or on any of the other transitions we should do (SELinux support, Debtags, ...), or even why we've lost this flexibility? The one idea I have for that is to try to do some hackfests. Like an init transition day, where a group of people tries to NMU most of the packages that have init scripts. Or adds "Homepage:" to most packages, which some important package metadata we only have on some packages. Or adding 'watch' files. Some of these would be easier if we had a common way of packaging and a central SVN repository. That would make it both easier to prepare the transition (e.g. committing init scripts beforehand) or especially for adding Homepage metadata and watch files without actually interfering with the maintainers work by not doing an upload immedeately, but just adding them to SVN so the maintainer includes them on his next upload. (Sorry, no comments enabled in my blog.) P.S. another thing I'd really love to see is a (semantic) PackageWiki for Debian, that has a Wiki-like structure with a page for each (Source-) package. Including things like e.g. Screenshots, Homepage link, Link to the Freshmeat page of the package, support lists/groups ... Kind of like the QA pages, but for the actual users, and editable by visitors.

I have a Debian wish for lenny:

• define and deploy a standard way of packaging software, that can be used for like 90% of packages. (It doesn't 'have' to be CDBS, it can be something 'better' for a reasonable definition of better. CDBS is the closest of the packaging tools I've tried so far, I've had single line package scripts with CDBS for many packages)
• Put the maintainer scripts into version control, it should be something with a central repository, but that of course allows maintainers to easily do a local branch. Especially for backports. Maybe SVN with SVK is okay.
• Use a standardized patch system along with a toolchain, quilt-like
• Link this patch management to upstream watching, so that patches applied upstream can automatically 'disappear'

Why do we really have to make a distinction between NMUs and maintainer uploads? I agree that we need to have someone (which can be a group) be responsible for packages and need to keep track of that to detect unmaintained packages (as well as to have someone track bug reports). With this central repository, we could have NMUs committed to the packages directly, and make contribution easier in general. For example, right now transations are usually added to a package via a bug report. The maintainer then needs to go through these bug reports (and some packages have so many open bugs I doubt the maintainer has a real overview over them; so he might easily miss some easy to fix ones), extract the patch and apply it to his package after review. With this central patch tracking system, the translators could just commit the translation change to the package directly, and it will end up in the next upload automatically. (Note that I'm not trying to force all packages to be maintained this way. I agree that for some packages it's not really appropriate. In general it should be left to the maintainers discretion. However I guess many team-maintained packages are handled in a similar way already, and I'd like to use that for my packages as well, even when not having Co-Maintainers. I'm also aware that when fixing security issues, you might not want to make your changes world visible immediately. This can however be done using SVK if we end up using SVN, for example.) Some rationale for this suggestion:

• Promotes team maintainance
• Offers another easy way of contribution (especially for sponsorees)
• Better change and version tracking
• Standard way of packaging makes NMUs and adoption easier
• Makes it easier to work on many packages when needed (e.g. new GCC version fixes, porters, translations, upstart support, SELinux support, Python, all kinds of transitions)

In fact I think that other distributions (e.g. *BSD ports, Gentoo?) are ahead of us in this respect, having a standard way of packaging and building things and keeping track of changes. Anyway, just my € 0.02 [Yes, I'm aware that this was covered in the DPL debate, but IMHO the point of different packaging preferences falls a bit short, and probably needs to be addressed first, before being able to have a central VCS for all packages. Also I think we should be able to find a common VCS we can all live with, or at least 90% of packages.] [And yes, I'm aware that this is a controversial topic that can easily start yet another flameware. But we need to find a way of keeping flamewars down anyway...]

München (Munich!) has a great swing scene - alive and kicking. Lindy Hop [wikipedia], Balboa [wikipedia], Boogie Woogie [wikipedia] (~ East Coast Swing) and Rock'n'Roll [wikipedia] (the acrobatic version) all over the place. Since starting dancing (RnR some years ago, Lindy a year ago, all just socially until about half a year where I took on the others as well and started going to some real trainings), they've become an essential part of my life that I wouldn't want to miss. If you happen to come to Munich, here are some links for you:

• Swing and the City, the homepage of Christine von Scheidt, a world class dancer and trainer as well as judge in some contests gives Lindy Hop classes that are excellent.
• The Cord (Sonnenstraße, very central location in Munich) has a great cosmopolitan flair and a swing night every monday, often with live music (which may or may not be great for dancing). Cat and Chris of 'Swing and the City' give teaser classes there, too.
• Salon Erna at Optimolwerke (near Ostbahnhof, also quite central, at the big party areal in Munich) is the home of Swing on Sunday. There is a beginners class as 19:30 with changing trainers and topic (usually Lindy Hop). While a bar like Cord, there are mostly dancers here.
• Swing it! is organizing social dancing events with livebands about once a month. Unfortunately, the previous location closed down (not due to Swing It, which got the place really crowded), but they'll hopefully find a new home soon.
• Boogie-Bären is the dancing club I'm in. They have four Lindy Hop classes on Tuesday, two Balboa classes on thursday and Boogie Woogie classes on most days.
• Near Fürstenfeldbruck (north-west of Munich) there is the Tanzfabrik Überacker where Fabi and Gino will take good care of you; I learned a lot from them in their classes at Salon Erna. They got me addicted to Lindy Hop. :-)
• Keep on Swinging, is the home of Fabi and Chrissi. They are giving occasional workshops at the Tanzfabrik
• If you are at the university for some time, got to the University Sports Programm. It's exceptionally cheap (like 7.50 EUR for a term for a regular student), and that includes lots of sport offers, such as a Rock'n'Roll and Boogie Woogie class. Thats where I started dancing before going to Berkeley, discovering Lindy Hop there and continuing it in Munich later on.
• Claudia and Horst, who also teach at Boogie-Bären, also give classes in Freising, north of Munich.
• And of course World of Swing: Markus and Bärbel are very well known dancers and trainers. If you are into swing, you probably have seen or met them already. They are giving Balboa and Boogie Woogie-Classes and organizing large dance events such as Rock that Swing or the "Munich Balboa Weekend".
• In summer, there will hopefully be a weekly dance event in Hofgarten park again, at the Diana temple.

P.S. My personal favourites / recommendations: Go to Cord or Salon Erna to see how much fun the community is, then take classes with Swing and the City or Keep on Swinging.

Another good day at South by Southwest. I had the night out last night, so I stopped at the Frogdesign Party for a while to see people and have some beers. I left to try to see Douglas Coupland's new movie, Everything's Gone Green. As a speaker I got a "gold" pass, which means I get to go see some of the films in the festival, but by the time I got to the theatre, it was at capacity. Too bad! Over to Club de Ville to see old friend Ben Cerveny, then trying to catch up with Niko, then an early night getting home. This morning I went to see Identity Woman (Kaliya Hamlin) talk about OpenID at the identity panel. It was a good discussion about identity and privacy, and I also got to meet Scott Kveton in person, too. Mike Linksvayer was there too, which was nice; it's great catching up with such a sympatico person. This afternoon I watched the incredibly valuable Everything You Always Wanted to Know About the Mobile Web...but Were Afraid to Ask. Great practical information for people willing to give mobile a try. I came away enthused and ready to make wikitravel.mobi a reality. Best of all was seeing Ben on his panel about virtual identity and avatars. Ben's got a talent for identifying the most intellectually stimulating thread in a conversation and following it with gusto, so it was really cool to see him talk on stage. tags: sxsw07 austin douglas coupland identity woman mobile web ben cerveny

La Traviata We stopped in for dinner at La Traviata, an Italian restaurant on Congress that Maj had heard good things about. The menu was nice but not too friendly to us pescevegetarians; we were excited when we heard that there was a seafood special that night. But the waiter came back to tell us that they weren't available. After we ordered, I heard the waitress behind me saying to her very big table, "...and we have two plates of the mahi-mahi available..." I stopped our waiter when he came by, and he was sheepish. "The chef was keeping those two plates for this big party." Oh. Our food was great -- I had a mushroom fettuccine, Maj had a grilled salmon with greens -- and we forgot about it. But the waiter came out later and said, "I talked about it with the chef and we want to extend our apologies. We should offer the specials to every customer equally. The chef wants to offer you dessert on the house." OK, sounds good. It doesn't take much to make up for a mistake, especially in the restaurant industry. La Traviata had good food, a really nice building, and great service up until then, but going that extra mile to make up for a mistake -- a debatable mistake I probably would have never thought about again -- gained my trust. More restaurants -- no, more businesses -- should have service like that. tags: la traviata austin italian restaurant

Blog review roundup I wanted to quickly shout-out to people who mentioned my talk at SXSW (Talks/SXSW07) in their blogs:

• Mike Linksvayer, SXSW: Commercialization of Wikis.
• Angela Beesley, Commercialization of wikis. I hope she saw that she was thanked at the end!
• Liz Henry, SXSWi panel on commercialization of wikis. The canonical notes, better than my own.
• Adam Darowski, SXSWi: Commercialization of Wikis. Adam's doing some wiki projects himself, and he found the talk helpful. Great!
• Mathieu Ouellet, Commercialization of Wikis. I hadn't seen Mathieu's great travel/tourism blog before, but it's bookmarked now. Great reading.

I'm really glad to see so much positive response to the talk. I worked really hard on it, and the subject is obviously very dear to my heart. It's great when your work pays off and people appreciate it. tags: sxsw07 me talk blogs wiki

Wiki BOF We're having a Wiki BOF lunch tomorrow at the 4th-floor coffee lounge. It should be fun. Thanks for announcing it, Liz! tags: wiki sxsw07 bof flock together

I've started using Yahoo Pipes today, and it's pretty cool. I wouldn't go so far as to call it a "milestone in the history of the Internet", but there are a few interesting use cases. Say for example if you're an avid reader of Planet Debian and you don't like the French Revolutionary Calendar, then you can use Pipes to filter out entries whose title matches a French Revolutionary month and enjoy a 100% revolution-free Planet. Or you could split matching entries into a separate feed, or just use regexp replacement to translate them into something else, etc. The possibilities are endless.

There's also a handy Babelfish module, so you can create a pipe that takes Planet Debian, translates it to French, then back to English. Hours of fun!

So after a busy week at work and a rather busy day yesterday (with a rehearsal of the ensemble, then me volunteering to do the bar at a musical of one of the other choirs of the same group as the one I'm in, and then finally the DPL debate), I decided not to do anything remotely useful today. Since the weather was nice, I went to the city. As I arrived there, walking around to figure out something interesting to do, I passed by 'De Muze', a well-known Antwerp jazzcaf (which either does not have a website, or has managed to hide it quite well). Since it was about 14:45, and they start live concerts there at 15:00 on sunday, I stayed for a while. After that, I went walking around in the city some more, enjoying the sun, eventually going through the Sint-Annatunnel (known to us Antwerp people as the "Voetgangerstunnel" -- pedestrian's tunnel -- since that's what it is), and stayed on the other bank of the Schelde for about an hour. Went home again, then, and had dinner. I'll probably have a lot of questions to answer on -vote by now, but I just don't care for now. Tomorrow is another day.

Inbetween working late and moving, I went for a relaxing weekend to my parents. Though ended up going out for a poker night. After passing out in a pram full of teddy bears, I was awakened a couple of hours later of my phone ringing. My sister was in panic and asked if I was at home with my parents.
She informed me that my father had passed out while he was talking on the phone with her and made strange noises that sounded like his lungs were being emptied.
I paniced, being far away and in the middle of nowhere with no car, I had to wait 45 minutes for a bus, that used roughly 30 minutes to get back home to my parents.
We didn’t know what had happened, we could not get a hold of my mother and thought my father had had a stroke or heart attack with noone around.
We eventually got a hold of my mother, who had called an ambulance, who refused to pick him up because my dad was concious at the time of their arrival. Bastards.
After busing and running home I dragged him into the hospital and insisted that he’d have a CT-scan.
Turns out he had had a non-epileptic seizure. Apparently happens if you push yourself too much.
Having a fright like that really makes you appreciate the presence of those you love. In other news; Time and place of the Helsinki March event has been decided. Sign up, people!

44 translated template files remain in the BTS. I will rest and wait for them to be uploaded. It’s not yet the time for Russian translators to panic :-)

As the first step in moving my automated d-i install testing away from the dilab and over to emulation, I've added support to the d-i regression tester (digress) to use qemu for serial-console based CDROM installation tests. It was fairly straightforward to do that, since digress already supported bochs and hercules. I don't currently have an enourmous fast machine I can run qemu on. Actually, all of my servers, including my only amd64 server, have xen on them, which isn't ideal in combination with qemu (no kqemu..). So I thought I'd put this out as a howto, in the hope that lots of people will set up their own automated tests. If you do, please mail me and let me know, and I will aggregate all the tests together into a nice status page. Here's how to set it up:

• sudo apt-get install qemu subversion libexpect-perl expect lockfile-progs
• sudo apt-get install kqemu-modules-2.6.18-4-686 # or similar, using unstable
• sudo modprobe kqemu
• svn co svn+ssh://svn.debian.org/d-i/trunk/scripts/digress
• Now edit digress/schemes/qemu/common, and set ISO to point to the CD image you want to test. You may also want to tune QEMU_DISK_SIZE, QEMU_EXTRA_PARAMS, STAGE_1_MAX_TIME, STAGE_2_MAX_TIME, and USER_PASSWORD. digress's README has more details about all the config options.
• Also edit digress/schemes/qemu/d-i, and change "url=kodama" to control where d-i will download its preseed file from. Until qemu bug #414342 is fixed, it can't support colons or slashes in the url to the preseed file, so the example is taking advantage of the default url guessing in d-i, which will look in eg http://kodama/d-i/etch/./preseed.cfg. Put in your hostname and set up a preseed file. digress/preseed.cfg is a reasonable starting point.
• To start a test, run ./test-harness qemu d-i
• The test will proceed automatically; digress will hit Enter at any prompts. Your preseed file should take care of any other choices.
• To cron the test, run cd ~/digress; ./daily-tests qemu d-i (be sure to update the CD image too). This will drop logs into digress/logs, and if you put that directory up on the web, I can produce a nice status page.

(Wonder if I should make a package of digress?) A few ideas for things to test:

• netinst iso
• businesscard iso
• netboot mini iso
• true netboot (qemu -boot n)
• gnome desktop install
• kde desktop install
• xfce desktop install
• web server install
• lvm
• raid
• small disk
• lowmem
• amd64
• lilo
• all kinds of fun combos of the above, like lowmem gnome+web server install on lvm

On Wednesday March 7th, I announced the end of the "blitz" l10n NMU campaign. This campaign started on January 21st after a first campaign during Autumn 2006. The main point was dealing with all pending l10n issues reported against packages, with etch as the main target and French reaching 100% as the secondary target..:-) This has been a great success, thanks to the collaboration of maintainers, translators and release managers. I have no statistics on the number of closed bugs and uploaded packages (shame on me), but at some moments I did up to 8 uploads in the same day. The pending l10n bugs page clearly shows that, except for a few packages for which maintainers have various, good and bad reasons to refuse a NMU and a maintainer upload, the situation is now quite clean. Release constraints now enforce more and more care with uploads, so it's time to suspend the action and move to another jihad (not officially announced yet, I'm preparing the material and announcement).

So, that was the debate. Now I can stop and read the answers properly. It was a bit disappointing that one candidate (gustavo) didn't appear, one was late (sjr) and one withdrew on the day of the debates (svenl). I guess I'll see what explanations are submitted. The debate opened with a fairly gentle question, asking for introductions. Makes sure the process is working, I guess. Generally inoffensive, but Anthony Towns's answer is puzzling: shouldn't he have documented stuff during the last transition if he thought it lacking? If he's re-elected, there won't be a transition, so any documentation would be based on year-old memories... he's giving an argument for electing someone else! The communication question got a variety of responses. Not sure that Wouter Verhelst's aim of better team communications is achievable, but maybe it is - don't know without more communication from people who aren't currently communicating well! Not sure whether Steve McIntyre is arguing for diplomacy and politeness or the truth of the Sapir-Whorf hypothesis, which is more worrying. Releases. Oh! Releases. Aigars Mahinovs's plan to release less often is interesting, but is it realist or defeatist? None of the candidates seem keen to give NM the radical revision that I think it needs - the median time in DAMnation is longer than the median time for the whole of the AM-led review, contrary to what Wouter Verhelst seems to claim later (line 754). About the only reforms suggested are Anthony Towns making permissions more gradual and Steve McIntyre's (IMO scary) social conformance test. Each of the candidates sees a slightly different thing as debian's biggest problem, although some of them overlap. Maybe this is the axis that differentiates the candidates most? Also, a full range of "code of conduct" views seem to be there: from it being a good idea, through leaving it for others to try, to being opposed. Then it was onto the buck-passing round. Another communication question brought some similar responses and this absolute gem from Aigars Mahinovs:-

"A technical solution to a social problem - a cron job that will send the email every two months, 6 text files with a template saying that nothing has been done and I just need to remember to write something good into those files before they are sent."

I like that idea! A few technical questions brought some interesting reminders about work that is actually already underway, but maybe not very visible, then there was a question about other distributions. Predictably, most of the focus fell on Utnubu and other derivatives, with a few mentions of Gentoo too. The targetted questions brought a few amusing replies: at least one candidate seems to say that they won't pursue a past comment if elected, while Anthony Towns seems to see the new FDL and CC licences and GPL'd Java as personal achievements. The cage fight (or open discussion, as it is more usually known) spent most of its time emphasising and clarifying points from earlier. It only seemed to be at the end when it cut new ground, with questions about demographics and $10million. Finally, closing summaries again showed the differences of approaches and views. Then that was that and the participants logged off into the night...

• The debate
• The audience
• The sources

Late this afternoon I had a visual migraine while driving. I was driving west and the glare from the sun was making it difficult to see so I didn't realise that I was having a migraine until I stopped. When I finished my journey and went inside a reasonably dark room I started seeing flashes of light (which weren't apparently bright enough to be noticed when outside). After about an hour the visual effects went away but I still felt weird for the rest of the day.

When I first moved to Canberra to work at Asia Online, I was staying at the Waldorf, and working in Braddon, so it was a really nice short skate to work. I think skating around after work in the summer time (with daylight saving) was one of the things that made Canberra really grow on me. I managed to destroy the (fairly cheap) blades in an incident in Commonwealth Park, and then lashed out on a more expensive pair of Bauer skates, which I subsequently hated. The original pair were simple, had a good hard shell, and three ski-strap style buckles, so they provided pretty good ankle support. The Bauers, on the other hand, had to be bought in a women's size because apparently my feet were too small for the men's sizes, were lace up, and had two Velcro straps that went around the top of the laces. I really made a terrible purchasing decision in getting them, because I found I could never get them tight enough around my ankles, and they were too tight around my toes, and were generally quite uncomfortable. Anyway, fast forward something like seven years to today, and I've been meaning to try skating to work to see how long it took. This morning, Sarah felt like some Vegemite, and I've got two bottles at work, and we seem to have run out at home. Sarah proposed that we cycle into work to get one of the bottles, and I thought this would be the perfect time to try out the skates again with no time constraints. So, I pulled them out, got to try out the new safety gear that I think Sarah got me for my birthday 2 years ago, and we headed off down the Stevens Creek trail. Things started out okay (as they always tended to do) but by the time we got to the La Avenida exit from the trail, I was feeling like a quick break to give my feet a breather, and I realised that the back left wheel had pretty much shredded itself. Seems the wheels don't have a fantastic shelf life. So Sarah cycled back home and got the car, and we aborted that adventure. I think rather than persisting with a pair of skates that I totally hate, I'll replace the wheels and give them away to Good Will, and look at getting a new pair that suck less. I think after waiting six or seven years between pairs is long enough get over the few hundred I spent on this pair. We're going to stay in San Francisco next Friday night after a party, so I think I'll go check out this store on Saturday. Hopefully I can make a better purchasing decision this time around.

We the undersigned petition the Prime Minister to promote the use of Open Document Format within the UK government.

Government documents must be available for tens if not hundreds of years. Currently much electronic documentation is stored in proprietary formats, such as Microsoft's .doc format. In order to allow future generations access to these documents it is imperative that they be in a fully documented standard. Open Document Format (ISO/IEC 26300:2006) is now the international document standard and as such should be supported by the Government.

The Weston Mercury - News: Council chief probe costs 34k

This happened in North Somerset and I remember something similar happening in West Norfolk. When will councillors stop using expensive lawyers to defend themselves at the taxpayers' expense?

opensource - epetition response

Ambivalent reply from the PM's office.

Town and parish councils

Kewstoke is used as a case study, but the link goes nowhere now...

The Irascible Professor-commentary of the day 02-08-07. Movie star teachers.

I've given up watching hero-teacher films. It's really not like that. I guess the oppressive bureaucracy of state education, with pressure from executive teachers to fiddle the student numbers, wouldn't make a good film.

The Irascible Professor-commentary of the day 03-06-07. Why I hope mhy children won't become educators.

Don't let your children grow up to become salesm^Wteachers.

NO2ID:newsletter 66

"Saturday, 10th March - King's Lynn street stall to advertise forthcoming public meeting, from 10am. Volunteers needed! Contact kings.lynn@no2id.net or text/call James on 07778 966395."

Tories want to free (software) Whitehall

The shadow chancellor gets all over the BBC as a result of his party's latest conversion.

Neighbourhood Fix-It

Another better-than-local-councils system from MySociety.

Concerto for blunt instrument: Ode to the No Longer Active

"We held a place for you // But you were busy // You've been so busy lately."