A few weeks ago Zack wrote about preparations for a new podcast to be called 'This Week in Debian'. I volunteered to be interviewed, and have now talked with Jonathan Nadeau for about 30 minutes about the work of the kernel team and the release process. Hopefully he'll be editing down my rambling so the first episode won't be too boring! If you do work on Debian that you'd like to talk about to an interested audience, follow the link above and yourself to the list of potential interviewees.

Update: Need to add Danga (Gearman), Liip.ch with Okapi, Flux CMS, Jackalope

It s widely regarded that to solve reliability problems you can just install a cluster. It s quite obvious that if instead of having one system of a particular type you have multiple systems of that type and a cluster configured such that broken systems aren t used then reliability will increase. Also in the case of routine maintenance a cluster configuration can allow one system to be maintained in a serious way (EG being rebooted for a kernel or BIOS upgrade) without interrupting service (apart from a very brief interruption that may be needed for resource failover). But there are some significant obstacles in the path of getting a good cluster going. Buying Suitable Hardware If you only have a single server that is doing something important and you have some budget for doing things properly then you really must do everything possible to keep it going. You need RAID storage with hot-swap disks, hot-swap redundant PSUs, and redundant ethernet cables bonded together. But if you have redundant servers then the requirement for making one server reliable is slightly reduced. Hardware is getting cheaper all the time, a Dell R300 1RU server configured with redundant hot-plug PSUs, two 250G hot-plug SATA disks in a RAID-1 array, 2G of RAM, and a dual-core Xeon Pro E3113 3.0GHz CPU apparently costs just under $2,800AU (when using Google Chrome I couldn t add some necessary jumper cables to the list so I couldn t determine the exact price). So a cluster of two of them would cost about $5,600 just for the servers. But a Dell R200 1RU server with no redundant PSUs, a single 250G SATA disk, 2G of RAM, and a Core 2 Duo E7400 2.8GHz CPU costs only $1,048.99AU. So if a low end server is required then you could buy two R200 servers that have no redundancy built in which cost less than a single server that has hardware RAID and redundant PSUs. Those two servers have different sets of CPU options and probably other differences in the technical specs, but for many applications they will probably both provide more than adequate performance. Using a server that doesn t even have RAID is a bad idea, a minimal RAID configuration is a software RAID-1 array which only requires an extra disk per server. That takes the price of a Dell R200 to $1,203. So it seems that two low-end 1RU servers from Dell that have minimal redundancy features will be cheaper than a single 1RU server that has the full set of features. If you want to serve static content then that s all you need, and a cluster can save you money on hardware! Of course we can debate whether any cluster node should be missing redundant hot-plug PSUs and disks. But that s not an issue I want to address in this post. Also serving static content is the simplest form of cluster, if you have a cluster for running a database server then you will need a dual-attached RAID array which will make things start to get expensive (or software for replicating the data over the network which is difficult to configure and may be expensive), so while a trivial cluster may not cost any extra money a real-world cluster deployment is likely to add significant expense. My observation is that most people who implement clusters tend to have problems getting budget for decent hardware. When you have redundancy via the cluster you can tolerate slightly less expected uptime from the individual servers. While we can debate about whether a cluster member should have redundant PSUs and other expensive features it does seem that using a cheap desktop system as a cluster node is a bad idea. Unfortunately some managers think that a cluster solves the reliability problem and therefore you can just use recycled desktop systems as cluster nodes, this doesn t give a good result. Even if it is agreed that server class hardware is used for all servers so features such as ECC RAM are used you will still have problems if someone decides to use different hardware specs for each of the cluster nodes. Testing a Cluster Testing a non-clustered server or some servers that use a load-balancing device at the front-end isn t that difficult in concept. Sure you have lots of use cases and exception conditions to test, but they are all mostly straight-through tests. With a cluster you need to test node failover at unexpected times. When a node is regarded as having an inconsistent state (which can mean that one service it runs could not be cleanly shutdown when it was due to be migrated) it will need to be rebooted which is sometimes known as a STONITH. A STONITH event usually involves something like IPMI to cut the power or a command such as reboot -nf , this loses cached data and can cause serious problems for any application which doesn t call fsync() as often as it should. It seems likely that the vast majority of sysadmins run programs which don t call fsync() often enough, but the probability of losing data is low and the probability of losing data in a way that you will notice (IE it doesn t get automatically regenerated) is even lower. The low probability of data loss due to race conditions combined with the fact that a server with a UPS and redundant PSUs doesn t unexpectedly halt that often means that problems don t get found easily. But when clusters have problems and start calling STONITH the probability starts increasing. Getting cluster software to work in a correct manner isn t easy. I filed Debian bug #430958 about dpkg (the Debian package manager) not calling fsync() and thus having the potential to leave systems in an inconsistent or unusable state if a STONITH happened at the wrong time. I was inspired to find this problem after finding the same problem with RPM on a SUSE system. The result of applying a patch to call fsync() on every file was bug report #578635 about the performance of doing so, the eventual solution was to call sync() after each package is installed. Next time I do any cluster work on Debian I will have to test whether the sync() code seems to work as desired. Getting software to work in a cluster requires that not only bugs in system software such as dpkg be fixed, but also bugs in 3rd party applications and in-house code. Please someone write a comment claiming that their favorite OS has no such bugs and the commercial and in-house software they use is also bug-free I could do with a cheap laugh. For the most expensive cluster I have ever installed (worth about 4,000,000 UK pounds back when the pound was worth something) I was not allowed to power-cycle the servers. Apparently the servers were too valuable to be rebooted in that way, so if they did happen to have any defective hardware or buggy software that would do something undesirable after a power problem it would become apparent in production rather than being a basic warranty or patching issue before the system went live. I have heard many people argue that if you install a reasonably common OS on a server from a reputable company and run reasonably common server software then the combination would have been tested before and therefore almost no testing is required. I think that some testing is always required (and I always seem to find some bugs when I do such tests), but I seem to be in a minority on this issue as less testing saves money unless of course something breaks. It seems that the need for testing systems before going live is much greater for clusters, but most managers don t allocate budget and other resources for this. Finally there is the issue of testing issues related to custom code and the user experience. What is the correct thing to do with an interactive application when one of the cluster nodes goes down and how would you implement it at the back-end? Running a Cluster Systems don t just sit there without changing, you have new versions of the OS and applications and requirements for configuration changes. This means that the people who run the cluster will ideally have some specialised cluster skills. If you hire sysadmins without regard to cluster skills then you will probably end up not hiring anyone who has any prior experience with the cluster configuration that you use. Learning to run a cluster is not like learning to run yet another typical Unix daemon, it requires some differences in the way things are done. All changes have to be strictly made to all nodes in the cluster, having a cluster fail-over to a node that wasn t upgraded and can t understand the new data is not fun at all! My observation is that the typical experience of having a team of sysadmins who have no prior cluster experience being hired to run a cluster usually involves learning experiences for everyone. It s probably best to assume that every member of the team will break the cluster and cause down-time on at least one occasion! This can be alleviated by only having one or two people ever work on the cluster and having everyone else delegate cluster work to them. Of course if something goes wrong when the cluster experts aren t available then the result is even more downtime than might otherwise be expected. Hiring sysadmins who have prior experience running a cluster with the software that you use is going to be very difficult. It seems that any organisation that is planning a cluster deployment should plan a training program for sysadmins. Have a set of test machines suitable for running a cluster and have every new hire install the cluster software and get it all working correctly. It s expensive to buy extra systems for such testing, but it s much more expensive to have people who lack necessary skills try and run your most important servers! The trend in recent years has been towards sysadmins not being system programmers. This may be a good thing in other areas but it seems that in the case of clustering it is very useful to have a degree of low level knowledge of the system that you can only gain by having some experience doing system coding in C. It s also a good idea to have a test network which has machines in an almost identical configuration to the production servers. Being able to deploy patches to test machines before applying them in production is a really good thing. Conclusion Running a cluster is something that you should either do properly or not at all. If you do it badly then the result can easily be less uptime than a single well-run system. I am not suggesting that people avoid running clusters. You can take this post as a list of suggestions for what to avoid doing if you want a successful cluster deployment.

In the evening today (Tuesday), the Debconf organizers arranged for a screening of the Creative Commons licensed film "Sita Sings the Blues" by Nina Paley. I went to see it as I had missed it when it was first released among tales of trials and tribulation at the hands of copyright meanies. So first let me say yay Free Culture!, boo Intellectual Property! etc. etc. Now we have that out of the way... "Sita Sings the Blues" has two main narrative threads: The breakup of Ninas relationship with her boyfriend and the Ramayana particularly a story from the uttarakanda about how after Shri Rama returned from Lanka, Sita had to undergo the agnipravesha to prove her chastity and even after she passed that test was eventually banished to the forest. I had an adverse reaction to this film. In fact I stayed to the end to be polite but I left afterwards as soon as I could. I had almost a physical feeling of nausea and I was surprised by this. Since then I have been pondering why this is so. It's not that its blasphemous. Shri Rama is not just a "perfect man", he is God (an avatar of Vishnu Bhagavan as is briefly touched upon in the film) for millions of people so, well, yes it is blasphemous but its more Rowan Atkinson style rather than Norwegian Black Metal style blasphemy. One never gets the impression that the author hates Hinduism or Indian culture the opposite in fact. And in fact it is not uncommon in our culture to speak of Sita and Rama in this way. They are not remote authority figures but as familiar to us as our own friends and family and the Ramayana is not just about events that happened long ago it is relevant to our lives right now. Even the "good woman done wrong by big dumb male jerk" narrative is not unknown. (See the Uttararamacharita of Bhavabhuti for instance.) though I would suggest reducing the Ramayana this way is akin to treating the Hitchhikers Guide to the Galaxy as a book about towels. Even the milder criticism that it is not accurate is offbase because although the Sanskrit poem by Maharshi Valmiki is the canonical rendition of the Ramayana, there are other well-known versions. Not just in Sanskrit, the Hindi retelling by Sant Tulsidas called Ramacharitamanasa is more popular than Valmiki. Also speaking as someone who has preached Ramakatha "professionally" I can tell you that even the priests do not stick to the letter of the text. It is encouraged and expected that they will riff on the basic stories adding or removing details according to the needs and taste of the audience. And the device of the three narrators made me smile as this is exactly the kind of discussions that go on after hearing the Ramakatha. (I must say Paley picked a notably illiterate trio though.) One place where this fell flat was when they discussed the alleged discrepancy between Sita living simply in the forest and dropping a trail of jewellery on the way to Lanka. Although I can imagine someone at some point saying, "Do not question these stories" not at this point. Even the most retarded westernized Indian would know that removing ones ornaments is a sign of widowhood. A married woman would only do that in extremis certainly not just merely because she was a hermit. In a few cases some extra details might have helped the story. It was not explained that Ravana does not just have rakshasas in his command but he is one himself. (And he certainly wasn't a good guy until one day he got up and kidnapped Sita.) Shri Ramas brother Lakshamana accompanied the couple into the forest to Lanka and back but he only pops up (for no apparent reason) at the end. But look at me, I'm turning into one of those people who rant about Star Trek continuity errors or complain that the Romans in a gladiator movie have the wrong helmets for that time period etc. One has to cut a storyteller some slack and I entered the screening determined to be charitable. It's also not because I don't really see much connection between the two stories. Getting dumped by someone who simply loses interest in you hardly seems equivalent to being trapped by a moral code that doesn't allow for individuals feelings. Paley could have easily made "Princess Leia Sings the Blues" and it wouldn't have changed the significance much. But in India people make far more tenuous connections between the epics and events in their own life so one can hardly complain about that. Aesthetics are not the problem either. The first version of the Ramayana I ever read was the Amar Chitra Katha comicbook version which partly influenced the visual style of this film. (In fact you briefly see it in one scene when different editions of the Ramayana flash by.) Hindu popular culture is very gaudy. (See Ramanand Sagars '80s Ramayana Hindi TV serial, which was very reverential, insanely popular and tacky beyond belief.) The animation in this film is very good and quite artistic. "So Jaldhar", you might be asking if you've read this far, "what exactly is your problem with this film?" I have read the Valmiki Ramayana in Sanskrit with the commentaries from beginning to end. I've read other Ramayanas in Sanskrit, Gujarati, and English. I have read the comicbook, I've read anti-Ramayana polemics. When you learn Sanskrit in the traditional way the first lesson, in the declension of masculine gendered nouns ending in vowels is rAma.h rAmau rAmA.h ... I am well aware there are different emphases, different interpretations in various versions. Why can't I accept this as just another take on a story that has shown its fluidity over and over again? It's just...wrong on a subrational level. How can I put this? Imagine you are flipping through the TV channels and you see your grandparents amongst Lady Gaga's backup dancers. Or you came home one night to find everything that was on the floor meticulously glued to the ceiling. Over the course of my life (to hear my mother tell it my first exposure to the Ramayana was before I could speak.) I have developed a mental bond with this story a certain idea of how it should be. I think so has Nina Paley. And this is the problem. "Sita Sings the Blues" is Nina Paleys Ramayana not mine.

The new roaming workstation profile in Debian Edu/Squeeze is fairly similar to the laptop setup am I working on using Ubuntu for the University of Oslo, and just for the heck of it, I tested today how hard it would be to integrate that profile into the university infrastructure. In this case, it is the university LDAP server, Active Directory Kerberos server and SMB mounting from the Netapp file servers. I was pleasantly surprised that the only three files needed to be changed (/etc/sssd/sssd.conf, /etc/ldap.conf and /etc/mklocaluser.d/20-debian-edu-config) and one file had to be added (/usr/share/perl5/Debian/Edu_Local.pm), to get the client working. Most of the changes were to get the client to use the university LDAP for NSS and Kerberos server for PAM, but one was to change a hard coded DNS domain name in the mklocaluser hook from .intern to .uio.no. This testing was so encouraging, that I went ahead and adjusted the Debian Edu scripts and setup in subversion to centralise the roaming workstation setup a bit more and avoid the hardcoded DNS domain name, so that when I test this tomorrow, I expect to get away with modifying only /etc/sssd/sssd.conf and /etc/ldap.conf to get it to use the university servers. My goal is to get the clients to have no hardcoded settings and fetch all their initial setup during installation and first boot, to allow them to be inserted also into environments where the default setup in Debian Edu has been changed or as with the university, where the environment is different but provides the protocols Debian Edu uses.

The problem: Splitting patches As a Debian maintainer, I often work with patches (files listing changes to text files), for example when tracking the modification I make to some software before I upload the package to Debian. To manage these patches, quilt is a nice tool: It helps you maintain a stack of patches on top of the original code and encourages you to keep your variously modifications separate. One use case is not supported by quilt at all: Splitting patches. One often has a large patch containing several independent changes. This might happen after you fix a few problems in the upstream code and then run dpkg-buildpackage, which will create one patch of your changes and put it in debian/patches. Before, I had to manually edit the patch and write the hunks, which are the building blocks of patches, into separate file. Where it already works There is no such problem when using a version control system, such as Darcs. Especially Darcs is rightly famous for its user-friendly interface and powerful hunk-selection features. You can even split a single hunk (which could be a change to one line) into two separate steps! Have a look at the HunkEditor page on the Darcs wiki to see how that works.
Let s steal a feature Well, it is not stealing if it is Free Software... Darcs has these nice capabilities and provides them in the context of version control systems, while we need them in the context of patch files. But Darcs is providing an API to its code, so shoudn t it be possible to create a program that uses the Darcs code to split patch files? As a matter of fact, it is possible: You can see that program in action on this 3min Ogg Theora-Video or directly here if your browser supports HTML5: Nice, can I use it? The code is a working proof of concept. What you see works. You do not see how it handles patches that create or delete files, patches that do not apply cleanly or are already applied or any kind of error handling. That does not work yet. If you still want to try it, you can grab the code from the Darcs repository at http://darcs.nomeata.de/ipatch, but you need to build the latest development state of the Darcs library first. I think ipatch could become a very useful and powerful tool with applications in areas where nobody would think of using Darcs. I definitely want some integration into quilt, replacing the splitted patch in the series by the replacing patches automatically. Maybe even a git plugin could be created? But I don t think I can push this project far enough on my own. So this is an invitation to join me and make ipatch a great tool. This invitation goes especially to the Darcs developers: Please have a look how the code uses the Darcs API and help to improve the collaboration here. I think we can use the darcs-users mailing list until there is need for a dedicated mailing list.

Stefano raised again the issue of providing some kind of Debian membership to people that contribute to Debian in unusual ways (not involving deep purely technical skills), like doing translation, documentation, marketing, design, etc. Each time this discussion comes back, people seem to think that we need another membership status for them. But what for? It s true that the name Debian Developer is suboptimal for non-programmers. But it s also suboptimal for most DDs, since most of us don t strictly develop software: we just maintain packages, mainly developing meta-data around the upstream source code. Debian Developer is how we call our full-fledged project members. Do we want to classify those non-programming contributors as second-class citizens? If not, we need to make them Debian Developers , not some strange other name. Of course, there s the issue of security and trust. Debian Developers have upload rights on all packages, and access to the project s machines. And it s a bit strange to trust non-programmers with that level of power. On the other hand, we have many Debian Developers that are mostly inactive, became DDs half a decade ago, and have the same access rights. Worst, it s possible that they remember how to use dput, having used it before! And 95% of DDs (me included) should probably not be uploading the libc, even if they can. Why should they be more trusted than active non-programming contributors that probably would be quite scared by the idea of breaking something? Overall, I think that this issue is actually a non-issue. We should:

• Acknowledge that, when a non-programming contributor has made notable contributions to Debian (proven by the advocacy of current members) and passed the relevant parts of the Philosophy and Procedures check, it should be made a Debian developer.
• Orthogonally, acknowledge that we have a problem with security due to the size and the volunteer nature of the project, and address it independently. For example, shell accounts could be disabled after 3 months without connecting to Debian machines (and be re-enabled by the DD on http://db.debian.org/). And upload rights could be limited to non-core packages (and extended by the DD on http://db.debian.org/ too). It s not about adding intermediate levels of membership, just about giving the possibility to developers to add a safe-guard against themselves.

Today was the first day of DebConf proper, where all of the sessions were aimed at project participants. Bits from the DPL (Stefano Zacchiroli) Stefano delivered an excellent address to the Debian project. As Project Leader, he offered a perspective on how far Debian has come, raised some of the key questions facing Debian today, and challenged the project to move forward and improve in several important ways. He asked the audience: Is Debian better than other distributions? Is Debian still relevant? Why/how? Having asked this question on identi.ca and Twitter recently, he presented a summary. There was a fairly standard list of technical concerns, but also:

• A focus on quality, as defined by Debian s highly modular approach. Each package maintainer is an expert on the software they package, and Debian as a whole offers a superior repository of packages.
• The principles of software freedom, as embodied in Debian s Social Contract. The Debian community s current interpretation is a purist one, and Stefano cited the elimination of non-free firmware as a milestone in the upcoming Squeeze release. I wonder, though, how many of the audience, tapping away on WiFi-connected laptops, were able to do so without such firmware.
• The project s independent status, supported by donations and volunteers, which empowers it to make its own decisions, free of external impositions.
• Debian s ability to make decisions, as embodied in the constitution. This happens mostly through do-ocracy (individuals are empowered to decide questions concerning their own work), though larger scope issues are decided democratically. This one evoked a bit of a chuckle, as decision making in Debian is not always perceived as fully effective.

He pointed out some areas which we would like to see improve, including:

• Developers accepting shared responsibility for the release as a whole. Making one s own packages ready for release is necessary, but not sufficient. He cited evidence that the culture around NMUs is changing: historically, due to the do-ocratic system mentioned above, Debian developers have been somewhat territorial about their packages, and non-maintainer uploads were seen as stepping on their toes. However, recent experiments have indicated that this may no longer be the case, and Stefano encouraged more developers to help each other through NMUs.
• When making decisions, we should seek consensus, not unanimity. In a project with thousands of contributors, whose operations are open to the public, there will never be unanimous support for a proposal, and seeking unanimity leads to stalled decisions.
• In order to gain more contributors, Debian needs to welcome new and inexperienced contributors, as well as users (who can grow into contributors. He suggested reaching out to derivatives to find more of both. He decried the conventional wisdom that a thick skin should be a prerequisite for joining the project, pointing out that this attitude simply leads to fewer contributors. This point was met with applause by the DebConf audience.

All in all, I thought this was an accurate, timely and inspirational message for the project, and the talk is worth watching for any current or prospective contributor to Debian. Debian Policy BoF (Russ Albery) Russ facilitated a discussion about the Debian policy document itself and the process for managing it. He has recently put in a lot of time working on the backlog (down from 160+ to 120), but this is not sustainable for him, and help is needed. There was a wide-ranging discussion of possible improvements including:

• Editing the policy manual so that it is more readable start to finish as a document, rather than a reference
• Creating a closer linkage between lintian and the policy manual, so that best practices from lintian get documented, and policy changes are accompanied by new checks
• Separating the normative and informative parts of the policy manual

There was also some discussion in passing of the long-standing confusion (presumably among people new to the project) with regard to how policy is established. In Debian, best practices are first implemented in packages, then documented in policy (not the reverse). Sometimes, improvements are suggested at the policy level, when they need to start elsewhere. I m not very familiar with how the policy manual is maintained at present, but listening to the discussion, it sounded like it might help to extend the process to include the implementation stage. This would allow standards improvements to be tracked all the way through from concept, to implementation, to documentation. The Java Packaging Nightmare (Torsten Werner) Torsten described the current state of Java packaging in Debian and the general problems involved, including licensing issues, build system challenges (e.g. maven) and dependency management. His slides were information-dense, so I didn t take a lot of notes. His presentation inspired a lively discussion about why upstream developers of Java applications and libraries often do not engage with Debian. Suggested reasons included:

• They are not interested in Linux as a target platform
• Although their code is released under a free license, they are not interested in meeting Debian standards for freedom and license correctness
• They use Java because it is cross-platform, and so do not want to concern themselves with platform-specific issues
• Because Java applications are easy to download and run manually, they perceive relatively little value in the Debian packaging system

Collaboration between Ubuntu and Debian (Jorge Castro) Jorge talked about the connections between Debian and Ubuntu, how people in the projects perceive each other, and how to foster good relationships between developers. He talked about past efforts to quantify collaboration between the projects, but the focus is now on building personal relationships. There were many good questions and comments afterward, and I m looking forward to the Debian derivatives BoF session tomorrow to get into more detail. Tonight is the traditional wine and cheese party. When this tradition started, I was one of just a handful of people in a room with some cheese and paper plates, but it s now a large social gathering with contributions of cheese and wine from around the world. I m looking forward to it.

DebConf being in New York City this year, clearly the right way to get there was to bike, together with Molly and Daf. Being touring newbs, there were a few mishaps.

Day 1 We aimed to catch the 10:00 commuter rail train from Boston to Providence, Rhode Island, but we ran late (predictable) and had problems with the bicycle rack for my racing bike, which attaches without frame mounts (also predictable, since Mako and Mika test-rode it earlier in the week), so we didn't make it in to the station until around 10:20. We used the extra time to eat and fix up the bikes, though, so it's not clear how much of a setback that was. Here are our bikes ready to go at the Providence commuter rail station. We then had some problems with Molly's brakes, and it took a long time to navigate out of the city, but eventually we found ourself on the "Washington Secondary Trail" a wonderful bike path along an old rail line. Every couple miles there'd be an old covered rail bridge over the river, and it was a well-paved straight shot for about ten miles, with no cars and no need to navigate. Just as we were getting into things after the bike trail ended, something completely unexpected happened. This is Daf's derailleur after it sheared off in the middle as we attempted to start after a red light outside Tractor Supply Co. Luckily, John and his son Chris lent us a hand and hauled Daf and his bike to the nearest bicycle shop in the back of their pickup truck. They'd just come from there, where John had bought Chris a new helmet. Greenway Cycles, the only bike shop in a twenty mile radius, was three miles away. We got there an hour before it closed and Rick replaced the derailleur and straightened the hanger in a jiffy. Due to all these things, we didn't get as far as we'd planned in the first day and ended up camping in Seaport Campground in Mystic, Connecticut, rolling in at around 22:00. We did about 65 miles, including six due to the detour to the cycle shop. Carrying camping gear is heavy! Several delicious peanut butter and jelly bagels and some wheatberry and couscous salad later, we were passed out.

Day 2 The second day included less bike trouble, but was no less eventful, and we were tired from the previous day's riding. The highlights included taking a tiny sidewalk path that I'm baffled how Google knows about up onto a sidewalk alongside the I-95 bridge across the Thames to New London, Connecticut. The 13:00 ferry from New London to Orient Point, New York, where we got some remarkably good veggie burgers (whole edamame visible!) for lunch. And a vineyard on the north fork of Long Island, where we stopped for a quick tasting and ended up picking up a bottle of barrel-fermented chardonnay. The vineyard was small 23 acres, with 11 acres of grapes and the proprietors were friendly and extremely interested in our trip. They gave us a dollar off on the bottle due to our method of transport. It turns out there are only two trains a day on the Long Island rail, and we just barely caught the 18:52 return from Riverhead. We had mere seconds in the station and ended up without enough cash to pay for tickets onboard, but the conductor just took what we had and gave us tickets to Penn Station anyway. Outside Penn, a girl with a mohawk and a messenger bag overheard us talking about biking up Broadway and told us to bike up 8th Avenue instead. "Always bike up 8th and down Broadway because they have bike lanes in those directions." Thus, we didn't die dodging taxis in the dark. So basically, due to various people being extremely nice to us for no good reason, we made it to Columbia University around 22:30, on the correct day. Warm fuzzies for humanity all around.

Like the Debian BTS, Launchpad is full of open bugs with patches[1]. They have an ongoing effort called Operation Cleansweep whose goal is to get the number of bugs with patches to zero, by reviewing patches and forwarding them upstream or to Debian. Since it really makes sense to expose bugs with patches to the Debian maintainers, I ve modified the Ubuntu box on the Packages Tracking System and the Ubuntu column on the QA Packages Overview (hidden by default for now) to include that information. You can see the result on the dpkg PTS page and the debian-pkg@ packages overview page. Many thanks to Brian Murray for making this possible on the Launchpad side.

---

[1] Debian has 55115 open bugs affecting unstable, of which 4011 have a patch. Ubuntu has 76916 open bugs, of which 2207 have a patch. [Insert here disclaimer that this is not at all a judgement of value on the abilities of any distribution at triaging bugs, or at generating patches]
Relevant UDD queries:

select count(*) from bugs
where affects_unstable and status = 'pending'
and id in (select id from bugs_tags where tag ='patch');
select count(*) from bugs
where affects_unstable and status = 'pending';
select count(distinct bugs.bug)
from ubuntu_bugs_tasks tasks,ubuntu_bugs bugs
where tasks.bug = bugs.bug
and distro in ('', 'Ubuntu')
and status not in ('Invalid', 'Fix Released', 'Won''t Fix')
and bugs.patches is true;
select count(distinct bugs.bug)
from ubuntu_bugs_tasks tasks,ubuntu_bugs bugs
where tasks.bug = bugs.bug
and distro in ('', 'Ubuntu')
and status not in ('Invalid', 'Fix Released', 'Won''t Fix');

The Flattr FOSS project is quite young so very few free software are currently listed in the dedicated directories. It s still advocacy time: if there are free software that you d like to flattr, please tell them and point them to Flattr FOSS. It s too early for any conclusion, but the feedback from users is good and it looks like that people using flattr to support free software are more generous than the average flattr user. You re great people! Anyway, it s time for me to give a few suggestions of projects to flattr.

1. My first recommendation is Project Hamster, it s a time-tracking application for GNOME but it has come a long way thanks to the work of Toms Bau is. I use everyday and it rocks.
2. My second recommendation is verallt, it s a Firefox extension that allows usage of Flattr even in places where it was not designed to be used: forums, mailing list archives, etc. The persons using Flattr just put [Flattr=20693] in their signature and the Firefox extension automatically replaces this text with a real Flattr button ready to be clicked. Thanks to Paul Da Silva for the nice idea and the first implementation!
3. My third recommendation is Mustard, it s a StatusNet client for the Android platform. More concretely you can install it on your Android phone to send updates to identi.ca while traveling. I have no Android phone but Mustard seems to be popular among owners of such phones!
4. My fourth recommendation is moreutils from Joey Hess. It s set of unix (command line) tools that nobody else thought of writing when unix was young (according to Joey himself). They are all very useful, I use more or less regularly isutf8 (verify if a file is UTF-8 compliant), combine (logical operations on lines of two files), pee (send standard input to two programs, very useful in git hooks when you want to run two programs that both consume the same data), sponge (ever tried grep -v foo file >file and lost your data? now you can use grep -v foo file sponge file ). And Joey is a long time Debian developer who has truly shaped Debian, he s behind several major Debian projects (debconf, debian-installer, debhelper, ). Big kudos to him!
5. My last recommendation is to flattr Andreas Gohr for his work as dokuwiki lead developer. There s no flattr button on dokuwiki s website but you ll find some in Andreas blog, just pick a dokuwiki related article like this one: Dokuwiki Birthday Bughunting Weekend. Dokuwiki is a simple wiki that works without any database (the pages are stored in flat files) and it s even commonly used to setup simple websites thanks to the numerous themes available.

Okay, that s it for this month. I ll try to keep a broad panel of software (desktop, command line, mobile, web, etc.). Since I have promoted a GNOME desktop application, I would like to be able to promote a KDE or XFCE application next month but I did not discover any KDE/XFCE project using Flattr do you know any? Please share in the comments if you find some. Also I wonder if you have decided of a flattr strategy Personally I m likely to flattr my favorites projects/persons each month and to flattr a few other occasionally as I discover them. What s your own strategy? 4 comments Support my work

I ve been working on a piuparts-like tool call instest (yeah, crappy name) to test installation, removal and upgrade of packages. Compared to piuparts, it s simpler and tries to make it easier to file bugs. However, running it on sid still raises ~3000 failures. So I m seeking help to analyze those failures and file bugs. The tasks are:

• get a grasp on what instest does, the script used to analyze the results, and the current results (yes, I know there are some obvious false positives).
• find possible improvements (isolate false positives or common error cases) and improve the scripts (no need to learn Ruby, I can help with that part)
• file bugs (there are scripts based on my archive rebuild ones to do that efficiently)

If you want to help, just contact me at Debconf!

So for one day a few days ago, I wasn't Wouter Verhelst, Debian Developer, but rather the above. I'm not usually very much interested in doing touristy things, but then on the other hand I'm of the opinion that you can't really claim to have been somewhere if all you've seen is the inside of a certain specific university campus. So, well, touristy things. I took the subway to about 10 blocks away from the very south of Manhattan, and then walked. I passed by city hall and what used to be the world trade center, but there wasn't much to see there construction sites are the same everywhere in the world. I moved on to "the battery", the south tip of Manhattan, and had an... interesting look at the Statue of Liberty in the distance. I thought about going there, but the tickets were sold out, so scratch that. Instead, I walked on to the Brooklyn Bridge (passing by Wall Street on the way), spent some time looking for the pedestrian's entrance to that bridge (which was slightly harder than would've thought it to be), and walked partway up the bridge. I wasn't interested in crossing over to Brooklyn, but it's an interesting bridge to walk on, and I had an interesting time. When I left the bridge again, it started raining. I don't mind a few drips on a warm day like that day, but this was more than that, and it started to bother me. So, rather than walking to the Empire State building, as I'd been planning, I decided to take the subway there. This did mean I missed out on the SOHO area, which I would've liked to see, but well, you can't have it all. The Empire State building is something you grow up hearing about, and I'd seen pictures of it. It has a somewhat distinctive silhouette, shown on several comparative graphics of high-profile skyscrapers. But none of that is even close to the real thing. Not that it's higher than I expected; on the contrary. But it does look different; its color is much lighter than I thought, and the distinctive silhouette isn't as distinctive once you're standing right next to the building. But, well, going up the building clearly shows that it is the tallest building of New York. There are other skyscrapers, but most of those seem to be little dwarves in comparison. The view is nice, up there, and I took some interesting pictures. The tickets aren't very cheap ($20), but not insanely expensive either. I don't regret doing this. (in case you were wondering: yes, the above picture is in the point of view of the one above that, and vice versa) By that time it was around 4 pm already, and I thought about going back to the Columbia campus. As I checked out my map for the most efficient route, I found that it probably would've been easier to walk to Times Square and take the number 1 train there which stops right in front of Columbia (but below the surface, obviously). So since I was going to have to go there, I figured I could just visit Times Square while I was at it. I must say I'm not very impressed by it. For starters, Times Square isn't actually a square, at least not as I'm used to that word. Broadway and 7th avenue happen to cross at a, for Manhattan, uncharacteristically sharp angle, which results in more space between buildings than usual. But it's still fairly small as a "square". They've fenced off a part of that space and put a bunch of chairs and tables there. This would be a cosy and inviting, "gezellig" place, if not for the very audible noise of the traffic still going on all around it, and the fact that everywhere you see, there's three layers of brustling and visually noisy adverts. It could have been a relaxing oasis in the middle of the city, but instead it's just as busy as everywhere else in Manhattan. But then, I guess that's what New York City is all about. At any rate, after spending about half an hour or so there, I walked over to the subway to get back to the venue just in time for dinner. The end of a nice, touristy, day.

According to Murphy s law, the fsck check that happens once every n boots always happens at the worst time. By default, using CTRL-C to abort it causes fsck to exit with an error, and the filesystem to be remounted read-only. It s easy to change that in /etc/e2fsck.conf:

[options]
allow_cancellation = true

After I finished an re-read my epic post describing my first day and a half at Debconf10 I suddenly realised that if I continue to describe the rest of 13 days here in such style and verbosity this would become a book, a boring one at that, so I decided to limit myself to 2 posts for Debcamp and then a post a day for the Debconf. But about the first half of the Debcamp week there are things that are as usual and there are things that are not. Let s start with the usual bits: more people arriving every day, evening parties are getting more and more fun and wild (or so people say) and the Internet and power at the hacklabs magically becomes more and more reliable day by day, the cabling mess grows organically trying to spread out evenly and not overload any individual socket, extension cords with non-local plugs appear and spread the load some more, people stress out, volunteer, crash out and repeat. All in all nothing can stop the freight train of few hundred Debian developers determined to have fun. With out own DFSG-free definition of fun. (But this year we appear to be running very close to the edge on volunteers if we run out of those, there will be a train-wreck, so please volunteer!) Now off to the unusual stuff. The City is well it is cool and very, very impressive. It is not terribly different to me at least I am used to such structure of the city: grid based layout of the downtown city (with some parks) and then branching out to separate, but different across-the-river districts and then sprawling out to slightly chaotic suburbs. Riga is very much like New York in the design. The difference is that New York is 10-20 times larger: the areas are 10 times larger, the buildings are 3-4 times higher on average, the streets are 2-3 times wider and yet have more traffic and there are far, far more shops, shows and restaurants. Also there is the subway. It is a great thing in that it hides the size of the city take a bus downtown once, to find out what I mean it takes ages to drive the distance that takes 20 minutes on the subway. I like this city, I am getting a feeling, that I could live here without much problem for me. So far I ve only had this feeling in Riga and Berlin. On the other hand this is USA. I ve so far only encountered one bad thing about it, but it is a pretty big one food. Basically all food that I ve tried so far in the USA has been crap. It was tasty salt, sugars and fat took care on my brain thinking it s food, but underneath that it was pretty crap: there was no texture, no content, no soul. The John Jay cafeteria where we are eating lunch and dinner is better than the most other options, because it is an all-you-can-eat buffet where you can choose your poison and it was also the place where I had the best piece of food in USA so far a slice of pepperoni pizza, that had a bit of taste behind the fat. Also, surprisingly, the fast food options (McDonalds, Burger King, ) are better than the equivalents in Europe, far better. In fact the fast food is cheap and in some cases tastes better than regular food, so there is no wonder why people might prefer it in some situations. So it is easy to see how people just accept shoving bland fast food or bland all-you-can-eat food into their mouths and not think much about it and thus become fat and put undue stress on their health. I expect the average weight of Debian developers to increase by 5 kg by the end of the conference. If you want to prove me wrong, running with bubulle would help you a lot with that. Events downtown. New York is a huge city with a lot of events going on every day, so everyone should be able to find something of interest for them. For me it was the free tickets for tapeings of The Daily Show and The Colbert Report. I got into both of those and for me The Colbert Report was by far the better experience. For one you can not get into Daily Show without a ticket (some tickets show up on the web site on the morning of the shoot around 11am), while 18 people from the stand-by list at Colbert Report got in. At The Daily Show you stand in a live line with ticket holders in one line and stand-by line separate. If you have tickets and arrive around 3pm you should be fine any later than that and you risk to be standing outside even with a ticket. You find that out around 4.30pm when they hand out physical tickets you have one, you get in. If not you might rush over to Colbert Report where a more humane system is used a staffer takes down your name and email on a numbered list and then you can walk around until 5.30pm then they let the ticket holders in and after that call the names of stand-by people that get in. The Colbert Report studio is brighter, more colourful and closer to the action, also it is very rare that cameras block the view from the audience (which is common on The Daily Show). It might have also been my luck when I got on the most boring The Daily Show episode I can remember, ever. The best joke was a woman asking John is she could get a ticket for her friend in August. The warm-up act and crowd control at The Colbert Report was also way better: Colbert staff was hyper, security was ever-present, warm-up was funnier and very engaging (he grilled me for several minutes and I replied making the audience laugh very hard explaining that Latvia was like India of Eastern Europe in regards to IT exports) and Colbert himself was very gracious talking to us out-of-character before the show for a good 10 minutes. Location, location, location. The talk rooms and event rooms and hacklabs are spread out across multiple buildings and there is a lot of other activities going on in those buildings besides Debconf, so moving between place might be confusing for the first day or two. Also the rooms are quite dark that might cause a noise problem for me and the video team as we ll have to up the sensitivity settings on our gear. The video team is working on fixing that by throwing a bit more light on to the speakers. Elevators are wicked fast, but can also be confusing, because the ground floor is on a different number for different buildings it can be G, 1 or even 4. Usually on campus there is a star next to the level with the exit. The dorms. I am in the Carman building and it looks like its interior has not been updated since it was built large ceramic bricks with very visible gaps (for the interior walls), raise-to-open windows, huge aircon fans that take up the whole bottom of the window, plumbing from the 60ies (at least). The security is weird on one hand you have to give your room card to the guard when entering the building, but on the other hand the room cleaning crew can simply forget to close your door after they are done. Like this Thursday I returned to the dorm just before lunch only to find the door of my room open. No one was around and nothing was missing, but it s still worrying. In any case I am steadily uploading photos from Debconf 10 to my Flickr page and new stuff should show up every day.

So an email went out to Debconf-announce with all this and MORE information but it is worth highlighting the talks/events as they are great. We look forward to having you in New York City! ********************************************************************************************************** exciting schedule highlights
- Have a look at the DebConf10 schedule,
there are a lot of really interesting things planned, both during Debian Day and DebConf
itself. We have a great line-up of speakers, and other events that are
sure to make this DebConf one to remember! A couple notable events that we wanted to highlight: Be sure to come to the DebConf Welcoming Plenary in the evening of Debian Day. This opening plenary will be the first thing that kicks
off DebConf and will be brief, important, and fun. General information
about DebConf, important logistical bits, and prizes(!) will be
had. Also, this gives you a chance to ask some questions before we get
started. Be there at 7:30pm in Davis Auditorium on August 1st! The much anticipated Cheese and Wine party will be happening in the
evening on the 2nd. This will be your chance to see what mixture of
fermented, cultured and alcoholic things your stomach can handle! Also exciting to mention is Eben Moglen who will be speaking on the
3rd during DebConf at 9:30am about Freedom and Privacy in the Cloud
and how we (yes us!) here at DebConf, can be the silver lining. If you
don t already know Eben Moglen
he is Professor of Law at Columbia Law School and founding Director of the Software Freedom Law
Center. Since 1993 he has served pro bono publico as General
Counsel of the Free Software Foundation. Moglen was part of Philip
Zimmermann s defense team when Zimmermann was being investigated over
the export of PGP. As counsel to the FSF, Moglen was charged with
enforcing the GNU General Public License (GPL) and later became
heavily involved with drafting version 3 of the GPL. Also in the evening of the 3rd at 7:30pm we will be treated to not
only a screening of the brilliant and beautiful and (award winning!)
film Sita Sings the Blues in
Pupin 301, but also a Q&A afterwards with the acclaimed animator Nina
Paley! She will describe how the process of making this film caused
her to question the wisdom of copyright monopolies in the arts. The
film is under a Creative Commons ShareAlike license, and her
distribution mechanism is unique as Paley consciously adopted the
methods of the free software movement to distribute the film. The
discussion with the artist after the screening will explain in depth
how and why, and discuss what Paley and QuestionCopyright.org are
doing next to encourage more artists to try the Free route. After the film, at 9:00PM the Columbia University Astronomy
Department will host a guided stargazing event, which includes use
of several different optical telescopes on their roof. There will be
astronomers on hand to answer any questions about the stars,
telescopes, or any other topics of scientific interest. There are many talks that are going to be exciting at Debian Day, even
for Debian Developers! One track will be showcasing general Free
Software themes and issues, and many of these talks will be really
interesting to Debian Developers, so be sure to check out the schedule and come On Debian Day we are excited to have the Honorable Gale Brewer speak at 4pm. She is part of the New York City Council and was the
former Chair of the Committee on Technology in Government, current
Chair on Committee on Governmental Operations and will discuss the
ways that government can foster freedom in technology. Its both
exciting and a privilege to have her speak at DebConf! day trip
This year, the day trip is going to be a blast, a crazy adventure at
the bizarre and fun Coney Island! Explore the historic RussianBrighton Beach! Ride the Cyclone rollercoaster, 82-years old this
year! Swim in the ocean! See the circus sideshow! Eat delicious food
or if unlucky, not so good food. Or do none of the above and just hang
out with your friends outside and have a good time. At the end of the day we are going to go to a unique cultural event:
the Brooklyn Cyclones baseball game where we will have the chance to
watch our beloved DPL humiliate himself as he throws out the first
pitch, in his Debian kilt! Don t like baseball, or sports? Don t worry, neither do we, but the point really isn t the baseball game,
the point is hanging out with all your closest Debian friends and
having a good laugh as Zack tries really hard not to trip, also a good
chance to experience some local culture and to relax after a hard day at the beach. free things in the city
There are an amazing number of free events happening in New York City during the summer! If you are looking for something to do, we ve
compiled a list of various events from a number of different locations
for you to easily view in one spot.

So an email went out to Debconf-announce with all this and MORE information but it is worth highlighting the talks/events as they are great. We look forward to having you in New York City! ********************************************************************************************************** exciting schedule highlights
- Have a look at the DebConf10 schedule,
there are a lot of really interesting things planned, both during Debian Day and DebConf
itself. We have a great line-up of speakers, and other events that are
sure to make this DebConf one to remember! A couple notable events that we wanted to highlight: Be sure to come to the DebConf Welcoming Plenary in the evening of Debian Day. This opening plenary will be the first thing that kicks
off DebConf and will be brief, important, and fun. General information
about DebConf, important logistical bits, and prizes(!) will be
had. Also, this gives you a chance to ask some questions before we get
started. Be there at 7:30pm in Davis Auditorium on August 1st! The much anticipated Cheese and Wine party will be happening in the
evening on the 2nd. This will be your chance to see what mixture of
fermented, cultured and alcoholic things your stomach can handle! Also exciting to mention is Eben Moglen who will be speaking on the
3rd during DebConf at 9:30am about Freedom and Privacy in the Cloud
and how we (yes us!) here at DebConf, can be the silver lining. If you
don t already know Eben Moglen
he is Professor of Law at Columbia Law School and founding Director of the Software Freedom Law
Center. Since 1993 he has served pro bono publico as General
Counsel of the Free Software Foundation. Moglen was part of Philip
Zimmermann s defense team when Zimmermann was being investigated over
the export of PGP. As counsel to the FSF, Moglen was charged with
enforcing the GNU General Public License (GPL) and later became
heavily involved with drafting version 3 of the GPL. Also in the evening of the 3rd at 7:30pm we will be treated to not
only a screening of the brilliant and beautiful and (award winning!)
film Sita Sings the Blues in
Pupin 301, but also a Q&A afterwards with the acclaimed animator Nina
Paley! She will describe how the process of making this film caused
her to question the wisdom of copyright monopolies in the arts. The
film is under a Creative Commons ShareAlike license, and her
distribution mechanism is unique as Paley consciously adopted the
methods of the free software movement to distribute the film. The
discussion with the artist after the screening will explain in depth
how and why, and discuss what Paley and QuestionCopyright.org are
doing next to encourage more artists to try the Free route. After the film, at 9:00PM the Columbia University Astronomy
Department will host a guided stargazing event, which includes use
of several different optical telescopes on their roof. There will be
astronomers on hand to answer any questions about the stars,
telescopes, or any other topics of scientific interest. There are many talks that are going to be exciting at Debian Day, even
for Debian Developers! One track will be showcasing general Free
Software themes and issues, and many of these talks will be really
interesting to Debian Developers, so be sure to check out the schedule and come On Debian Day we are excited to have the Honorable Gale Brewer speak at 4pm. She is part of the New York City Council and was the
former Chair of the Committee on Technology in Government, current
Chair on Committee on Governmental Operations and will discuss the
ways that government can foster freedom in technology. Its both
exciting and a privilege to have her speak at DebConf! day trip
This year, the day trip is going to be a blast, a crazy adventure at
the bizarre and fun Coney Island! Explore the historic RussianBrighton Beach! Ride the Cyclone rollercoaster, 82-years old this
year! Swim in the ocean! See the circus sideshow! Eat delicious food
or if unlucky, not so good food. Or do none of the above and just hang
out with your friends outside and have a good time. At the end of the day we are going to go to a unique cultural event:
the Brooklyn Cyclones baseball game where we will have the chance to
watch our beloved DPL humiliate himself as he throws out the first
pitch, in his Debian kilt! Don t like baseball, or sports? Don t worry, neither do we, but the point really isn t the baseball game,
the point is hanging out with all your closest Debian friends and
having a good laugh as Zack tries really hard not to trip, also a good
chance to experience some local culture and to relax after a hard day at the beach. free things in the city
There are an amazing number of free events happening in New York City during the summer! If you are looking for something to do, we ve
compiled a list of various events from a number of different locations
for you to easily view in one spot.

As I did since 2007, I will be attending Debconf again this year. I have been quite busy recently, and am lagging behind in some of my Debian work, so I plan to use Debconf to get stuff done, not just socialize and attend talks. Here is my TODO list, basically by order of willingness to do the work . It s probably too much for 9 days, so don t hesitate to talk to me if you want to help with some items.

• Switch the ruby1.9.1 package to a prerelease of Ruby 1.9.2. That package providing the development branch of the interpreter. That will be done while keeping the existing package name, as Ruby 1.9.1 and 1.9.2 are (supposed to be) compatible. It might be a bit confusing for users to have a ruby1.9.1 package that installs Ruby 1.9.2, but then we can just blame the upstream developers for using the same numbering space for ruby compatibility level and ruby version . Bonus: will fix 2 FTBFS on kfreebsd-, i386. ruby1.9.1 1.9.2~svn28788-1 uploaded, but it really means ok, enough, let s upload and see what happens . There are some open issues on FreeBSD, and some patches that still require porting to that version.
• Update the ruby1.8 package. There s a few patches pending (including the ruby is slow because of pthread one). ruby1.8 1.8.7.299-2 uploaded, sync to Ubuntu requested.
• Run an archive-wide test using instest again. instest is a piuparts re-implementation that is targetted at making it easy to file bugs about installation and removal failures. It s nothing big, really, but already allowed to file 78 RC bugs a few months ago. Done, and call for help posted. Which raises another TODO item:
  • Process instest failures if nobody wants to help
• Run an archive rebuild. I did one last week-end mainly to provide food for RCBC, but there are some failures that haven t been filed because they required more investigation. I also need to check back with various people about some custom rebuilds (newer GCC, etc). And I ll probably also do a rebuild of Ubuntu maverick.Rebuild done, about 70 new RC bugs filed, and some cleanup done on old unreproducible bugs. Also did a rebuild with an updated hardening-wrapper for Raphael Geissert, and a rebuild of Ubuntu maverick on i386 and amd64 (results posted on ubuntu-devel@).
• Do a ddpo-by-mail run. Last one was a longgg time ago. I have a few open requests about ddpo-by-mail that I d like to address before spamming people again (for example, it shouldn t report about merged bugs).Done, ~1300 emails sent.
• Ultimate Debian Database work: merge the upload-history importer into UDD itself to drop the dependency on a script on merkel. Also address #540132 (strange info in the upload-history table). Make sure the changes to carnivore about DMs are compatible with the carnivore importer.
• Investigate how we could improve Ruby packaging with something like ruby-support. One of the requirements is to provide an easier way to support several Ruby versions.
• Do some work on feed2imap. It got a few valid feature requests recently that I d like to address in a 1.1 release.
• Debian/Ubuntu work: add info about bugs with patches to the PTS now that this info is available in UDD thanks to Brian Murray s work on the Launchpad side, and other pending work items from the Debian/Ubuntu BOF at UDS
• Work on Bapase and the handling of poorly maintained and low-quality packages, resurrecting an old thread on debian-qa@
• Do some packaging work: systemtap 1.3, tcsh, websec (long overdue!), and the usual pkg-ruby-extras shores. I also would like to take a look at the atlas FTBFS as I m affected through hpcc.
• Update developers-reference. I m totally in lazy mode about that since the maintenance was transferred to debian-policy@, but I will try to address bugs with valid patches.

Here at DebConf10 the schedule is starting to get really packed of events, which is great! About a half of those events are BoFs (in the IETF sense), i.e. discussion sessions among people interested in specific topics. (Other conferences use "BoF" to refer to impromptu, non-scheduled, and spontaneous events, while at DebConf we have traditionally submitted, reviewed, and scheduled BoFs in advance.) As most DebConf regulars, I've attended quite some BoFs in the past and I share with others the impression that the quality and usefulness for the project of BoFs varies substantially from BoF to BoF. That's why I'd like to share a BoF recipe, which comes from possibly the best organized BoF I've ever attended. As it happens with all good recipes (and with free software), I've took the liberty of customizing it a bit.

---

DebConf BoF HOWTO have a coordinator A good BoF should have a coordinator, which is usually (but not necessarily) the person who proposed the BoF in the first place. The role of the coordinator encompasses at least 2 tasks: preparing the BoF in advance (read below) and moderating the discussion to ensure everybody get a chance to participate. prepare in advance A good BoF is more than just getting together, vaguely knowing the BoF topic, and ... discuss. Mind you, it might work very well that way too, but the chances of having a successful BoF are much higher if attendees arrive prepared. That is quite simple to achieve. It just takes the BoF coordinator to prepare some working questions and/or detailed discussion topics, and advertise them as such. That way potential participants can make up their minds, recall experiences that they want to share, note down comments they want to bring into the discussion, etc. In my experience, the BoF time will then be used in a much more productive, exciting, and ultimately fun way. Most BoFs can also benefit from a few introductory slides on the BoF topic, to ensure all participants start from a common ground. The last slide could contain a brief recap of the working questions, so that the audience have them handy. don't be exclusive Debian is not a company and Debian contributors are not employees, therefore we cannot expect all relevant people to attend a specific BoF, just if they had to. As usual, the risk of cutting off community members who cannot attend should be mitigated as much as possible. To that end, minutes are just great; after the BoF, minutes should be posted where appropriate, and possibly uploaded to Penta as event attachments. ... but taking minutes is just boring and not everyone is good at that (for instance, yours truly used to suck at taking minutes, even if I'm trying to get better ...). If you have a trusted participant which is good at taking minutes, great, go for it! If you don't, use collaboration. During past DebConfs as well as at UDS this year, I've been shown a nice way of doing that. It takes a dedicated projector in the BoF room showing some real-time, collaborative editing facility (e.g. gobby). With such a setup, people usually just start taking minutes collaboratively, although explicitly inviting the audience to do that is a very good idea. Ideally, the room should have two projectors, one for supporting slides, another for collaborative minutes taking. In case there is only one, as it is usually the case for DebConf, it's probably better to use it for minutes and switch to them as soon as supporting slides are over.

---

gobby.debian.net for BoF minutes at DebConf10 For DebConf10, the DebConf team has setup a gobby (infinote) server at gobby.debian.net. Just do the following in order to be ready for collaborative minutes taking:

    # apt-get install gobby-0.5
    $ gobby-0.5 -c gobby.debian.net

(Note: you shouldn't use the non versioned gobby package as it uses a different protocol and doesn't support undo, which is quite risky; see Debian bug #590753 for more background.) As the naming convention for DebConf10 minutes, using document names that start with dc10- sounds sensible.

---

comments welcome! So, what do you think of the above suggestions? Do you have further best practices to share on BoF organization at DebConf? Leave a comment or mail me. In the end it would be nice to author a proper "DebConf BoF HOWTO" document for further reference. Thanks to Gregor for his feedback on early versions of this post.

While I have made good progress on many of my Debian goals for this year, it s not the case for the goal number #1: translating my Debian book into English. The picture on the left is the cover of the current French version based on Debian Lenny (450 pages). But the translation would be based on the next edition that we re currently preparing and it s based on Debian Squeeze of course! We have already translated the table of contents so that you can get an idea of what s in the book. Note that many parts of the book apply to Ubuntu as well. It s quite difficult for Roland and me to allocate several months of our life to such a huge task without any income in that period and without knowing if our book will sell enough to cover for the time invested. For those reasons, we re considering using a service like kickstarter.com or ulule.com or yooook.net to get this project funded. If you don t know those services, they allow you to present your project and to collect pledges so that you can safely complete your project. The money pledged is distributed only if the total amount pledged exceeds the minimal funding level (set by the project creator). Furthermore you can select nice rewards depending on the amount of money pledged. To make things even more exciting we are ready to publish the book under a DFSG-compatible license at the sole condition that we reach 25 000 of donations. That might look like a lot but in fact it s only 5 donated by 5000 persons and then everybody benefits! And for the authors, you have to remove ~10% of fees taken by the funding service (including card processing fees), 16.4% VAT, 9% social taxes and if you consider that the project represents a minimum of 6 months of work, that ends up to at most 2850 /month. We believe this to be reasonable. The next step for us is to pick the service to use and setup the fundraising. We need your input. Please answer a few questions by filling this form. In all cases, we will have those rewards and probably more:

• the book in digital format (PDF, HTML, ePub) (between 5 and 10 , price not fixed yet)
• the book as paperback (between 35 and 50 , price not fixed yet)
• the paperback book with a dedication by (one of) the authors

A few considerations about the various services: Kickstarter.com is a great service but it s restricted to US-residents so it s complicated for us to use that service since we re French (and live in France) and the supporters need to have an Amazon (payments) account. Ulule.com is open to anyone for project creation but uses a paypal API to deal with the pledge mechanism and thus imposes that all supporters have a paypal account. Is that requirement likely to scare you away? Yooook.net is specialized in liberation fundraising but the interface is not very polished, they don t offer (many) social features nor do they give a public listing of the projects hosted. The choice is difficult and thus we re seeking your feedback to make the right one, take a few minutes and answer our questions: click here to go to the form. Thank you for your help and please spread the word so that we get enough answers to have meaningful results. Update: it has been brought to my attention that kickstarter requires an Amazon (payments) account. I fixed my article and the form to document this. I have also been asked what license we re going to use. It s likely to be dual-licensed GPL2+ / CC-BY-SA 3.0. 4 comments Support my work