Why you won't be voting for me for DPL this year. Or, my plans for Debian stuff over the next year (or three).

Most of these plans embody larger themes and directions that I feel Debian should take. I am a strong beliver that working code and getting stuff done is the best way to work toward larger goals, so I won't bother to try to explain the larger goals.

constantly usable testing

This is so important that it has its own page.

This is my first public posting of that proposal, and it should not be considered finished. I plan to finish it, and get to work on it.

website

www.debian.org is deprecated, but this is not obvious to either users or developers. That's because it's not formally deprecated, we just treat it like it is: We don't use it for anything new. Instead we have wikis, planet, times.debian.net, etc, etc, etc, etc.

Unfortunatly that has created a bit of a mess for users, who are still often stuck trying to use www.debian.org, or who can't find new stuff that is on other sites. A solution could be creating an alternate starting point for users, to help them learn about Debian, install it, and point them to docs and all the other useful sites once they're more involved and using Debian. I hope to find time to work on and promote such a thing.

I plan to continue moving stuff that needs to be maintained actively and grow off of www.debian.org to the wiki (as I've done with some of d-i stuff, for example), and encourage others to do so as well. Anything under /devel/ on www.debian.org is an especially good candidate for the wiki.

double the archive sync frequency again

Now that we've switched to updating the archive twice a day, and dealt with the (minor) issues caused by it, it should be easier to increase it to a frequency that is more likely to cause noticible turnaround time improvements and thus speed up some development. As it is, many people sleep through one or the other archive update. So I support doubling it to four times a day, or more (six seems better).

automated whole system testing

Automated whole system testing is important because Debian needs to keep working in so many obscure and annoying to test situations. Does d-i work on m68k? Does the desktop task install properly and work? Does debootstrap install a usable system on every architecture? If we rely on user reports, things can fall through the cracks entirely or not be noticed for too long.

I've been running a d-i lab for a few years, which tries to automatically test installs on 6 architectures. However, between the current kernel not supporting several of my test machines due to hardware and software bugs, and the general time sync of keeping a rack of aging and obscure test boxes working, this has not been very useful lately.

I feel that the solution is emulation: It should be possible to run Debian under emulation for most architectures. I hope to get an absurdly powerful server donated, and switch my test lab over to running in emulation on it.

developer (virtual) machines

The other benefit of emulation is that everything needed for testing stuff under emulation can be easily distributed to others. Getting developer accessible machines for certian architectures has been a problem in Debian. Emulated systems can sidestep this problem.

All that's needed is a collection of documents and/or bootable images that developers can use to set up virtual machines for as many architectures as possible.

We have steps in this direction. Hercules contains documentation for how to install in it using d-i. There is a kernel flavor and d-i boot images for mips on qemu.

Having to ssh out to a DSA adminned box to deal with a buld failure on $ARCH, and having to wait for build deps to be installed should begin to feel antequated and quaint. It is.

find the next nslu2

Debian's support for the nslu2 is an excellent development. It opens up using Debian for a whole new set of tasks, that need low-powered, semi-embedded, commodity hardware, that before were the province of special-purpose embedded distros. It also blew the popcon numbers for arm through the roof.

We need to find the next nslu2-like target and get to work on it. I'm hoping that it will be a wireless router, because that's the only thing I'm not running Debian on now. :-) But it could also be a cell phone, or PDA..