Using for project management

From the start of the DebianEeePC project, we have used a combination of the irc channel and our wiki site to our great advantage. The DebianEeePC/HowTo/Install document has been actively maintained as we go, serving not only as a good reference for new users, but also for existing users and developers to see where improvements are being made and what is left to work out.

Recently, we’ve started using the wiki for task management as well. Patterned after DebianInstaller/Bugs, we now have DebianEeePC/Bugs where we link to reports on the BTS for packages we maintain and our own usertags on packages we don’t maintain. As well, we are keeping a DebianEeePC/Todo to manage our tasks.

I see from a search through the wiki that lots of other Debian subprojects keep Todo lists, but most of them have little more structure than point-form lists. A few, though, have structured these pages a bit more carefully. For instance, some of these use tables listing who each task is assigned to, when it was assigned, and when it is completed. Our point-form list is a bit more free-form regarding task assignments. Participants can register their interest in a given task and what they are doing as a subpoint of the task. As for state changes over time, we rely on the revision history on “info” page for people to be able to see state changes for particular Todo items. When something is done, it just gets dropped from the list.

I haven’t exhaustively reviewed everyone’s Todo page, but from my brief survey I haven’t seen a couple of things I’ve added to try to help people choose what to do next. The first is to tag items with six difficulty/importance pairs, rating each actionable item from Easy/Urgent to Hard/Wishlist. The second is to state dependencies between items using anchors. It would be nice to see any of you are doing something similar and hear about whether it has worked out well for you.

I’m happy with how the irc/wiki combination has helped with project management. In the past with a different project I’ve made an abortive attempt to use the task management system at Alioth, but it just seemed too cumbersome and nobody ended up using it. With the wiki, it appears barriers to participation in task management are sufficiently lowered that everyone is willing to help keep it up. And with irc, we can keep on top of defining and assigning (or more usually volunteering to do) various tasks, and making sure the wiki is kept completely up to date. It takes a bit of discipline to do, but after the habits are established, it gets easier, and the rewards are well worth it.


Bits from the Debian Eee PC team

In the past few months in the Debian-EeePC team, a number of interesting things have been happening.

Progress has been made to ensure the Eee’s drivers get merged upstream. Chris Snook from Red Hat has taken over atl2 upstream and has started merging it with the atl1 driver to make a unified atlx driver that will be suitable for inclusion in the kernel. As well, there is continued progress on the madwifi driver, with a patch now included to support version 2.6.24 of the Linux kernel.

In the meantime, the Debian Eee PC Install HowTo has been under constant revision, even gaining recently the beginnings of translations in French and German.

ACPI, another important piece of infrastructure for the Eee, is now supported in lenny and sid through Eric Cooper’s eeepc-acpi kernel module. This is a fork of the asus-acpi module renamed so that it won’t conflict with the in-tree version. It turns out that asus-acpi is deprecated, having been replaced by asus-laptop. Eric has been in touch with the asus-laptop maintainer to ensure the Eee-specific bits are merged so that we can eventually retire our forked version.

There still remains at the top of our Todo list the issue of ACPI scripts to go with the kernel module. Having at first considered patching acpi-support, we have decided instead to start with Eric’s own scripts which will be packaged shortly for Debian. This gives us more freedom to tinker before considering submitting patches to more general laptop support packages like acpi-support.

Finally, after Brendan M. had to send his Eee back to Asus for repairs, work stopped for a while on the custom debian-eeepc installer. Fortunately, he just got his system back from the shop as good as new and has returned with renewed vigor to that task. He has produced a new version of the installer which we are now testing.

Thanks to the efforts of numerous users and developers who are being added to our ranks daily, we expect by the time Lenny releases we will be well on our way to providing a pure Debian solution for the Eee. Whether or not everything needed for the Eee is in Lenny at that time remains to be seen. We need to allow for how long it takes to get new drivers into the kernel. But if we miss the release, we will certainly provide backports and look forward to full support in the following release.


Fr-eee-dom: roaming on the bus with wpa_supplicant

As I wrote earlier, I bought an Eee PC to use on the bus. Initially, I only used it offline to do some Debian packaging and blogging, but I soon discovered that I could do a few things online on the many open networks on my daily commute. While the connections are normally brief in good traffic conditions, even a few seconds here and there is enough to participate in irc discussions.

Manually connecting to each got old very quickly. So, to automate those connections I settled on wpa_supplicant, (wpasupplicant is the Debian package name,) which is quite easy to set up in roaming mode, as outlined in /usr/share/doc/wpasupplicant/README.modes.gz. All you need is the following in /etc/network/interfaces:

allow-hotplug ath0
iface ath0 inet manual
        wpa-driver wext
        wpa-roam /etc/wpa_supplicant/wpa_supplicant.conf
iface default inet dhcp

Then create your /etc/wpa_supplicant/wpa_supplicant.conf as follows:


That’s it. You can now roam from one open network to the next and the supplicant will connect you to each one in turn. I have used this to reconnect to my screen session each time the bus slows down for a stop or gets stuck in traffic to carry on conversations on irc for the whole length of the commute.

If you also connect to networks requiring authentication, you’ll need to add a “network” clause for each network. See /usr/share/doc/wpasupplicant/examples/ for help with that, particularly the annotated conf file, README.wpa_supplicant.conf.gz.

For finer control over the process, I use sudo wpa_cli so i can:

  • keep an eye on what networks are around: scan, then scan_results,
  • disconnect from a network once I know it’s out of range
  • and reassociate as needed.

The only things that I haven’t figured out how to do yet are to make the process of switching from one network to the next a bit faster (it normally takes about a minute; precious seconds of online time are lost when the bus is in motion,) and to blacklist certain essids, e.g. commercial hotspots that make you pay before they’ll route your packets to the Internet. For the first problem, I have already tweaked my dhcp settings, which helps a bit. For the second, I tried adding network blocks for specific networks and setting them to a lower priority, but that doesn’t work because then the ‘catch all’ open network block kicks in and picks them up anyway.


Debian-eeepc now has atl2 ethernet

With Kel Modderman’s help, we now have a working atl2 driver for the Eee PC. This brings the Debian-eeepc project one step closer to providing a pure Debian replacement for the Xandros OS that ships with the unit. Now that Asus has released the GPLed source that was missing before, we now just have to ensure both the atl2 and asus_acpi modules get merged upstream.

The driver for the wifi in the Eee isn’t under the GPL, however, and therefore only works on the Xandros kernel provided with the default OS. Since I really can’t live without wifi and it is not my first choice to buy replacement hardware, in the interim, I’m living with using the Xandros kernel and modules on Debian. I can learn from studying the Xandros components in action, but it’s not a solution I’m happy with in the long term. The Debian-eeepc project’s goal is to produce a pure Debian solution, at least as far as that is possible given the hardware present in an unmodified system. On that front, I think the best bet is for ath5k to support the particular Atheros chip in the Eee. (Yes, I know about ndiswrapper, but for both technical and philosophical reasons I won’t use it.)


Debian-eeepc: the ideal mobile text editing device realized

The search for the ideal mobile text editing device is over. While the price was well over my original budget, we’ve since gone ahead and splurged on two new Eee PCs: one for me, one for my wife. In the end, I think it will be worth it because these systems are capable of far more than just editing text.

Now comes the challenging part. Xandros is the default OS and we want Debian on it instead. I have started supplementing the system with packages from Etch and Etch-backports using apt pinning, but already I have noticed some cracks beginning to develop: with pure Xandros, an SD card was automounted when it was inserted. Now it fails. Also, the Network utility no longer launches. I can work around these glitches for now, but it is plain that in the long term this Xandros/Etch hybrid is going to be more grief than it is worth.

To that end, enter Debian-eeepc. Building on the work started by timbobsteve and drawing from the collective experience of the community we will make a debian-live cd + debian-installer to install Debian (as pure as possible—obviously the kernel is going to be our most contentious issue) on the device. So stay tuned for more articles on that work-in-progress.

And how does my new toy shape up for mobile text editing so far? I’m delighted! For starters, this article was drafted on the bus home from work. The keyboard, while small, is still quite usable for touch-typing, the display is crisp and bright, and the size is just perfect for the cramped quarters of a public transit bus seat.

But beyond just editing text, I have loaded up the system with all of the tools that go around it: subversion, git, ruby, gcc, meld, etc. I’ll be able to manage a fair amount of development on the bus, with the exception being really large builds that will continue to be done on remote build systems.