Lars Wirzenius: Debian, 2006
Contents
- December 04: Tattoo
- November 02: Something Positive and vocal minorities
- October 30: BSP @ Helsinki
- October 13: A discussion wiki?
- October 11: Debian sources in bzr, Eric Dorland is right
- October 03: Joey Schulze is wrong
- October 02: Piuparts et al orphaned
- September 03: A code of conduct
- August 15: Installation videos
- August 02: LowThresholdNmu at 102
- July 28: Project Ummikko
- July 14: The Debian Vacation Event
- July 07: Photo mosaics of Debian logos
- June 28: Re-qualification of Debian developers
- June 19: Packaging tutorial (again)
- June 13: Packaging tutorial/workshop
- April 25: Packaging tutorial clarification
- April 16: Flames you never see
- April 12: Packaging tutorial next summer in Finland?
- March 15: Watch files, last time
- March 13: Why I don't make watch files
- March 08: NMU / rc bug fixing checklist
- March 05: A big momentum hug
- March 03: D-W Python tutorial
- February 27: FOSDEM slides up
- February 11: Device driver check page
- February 06: What kind of DPL?
- January 18: One more about the OpenSolaris talk at Debconf6
- January 11: On using phones
- January 05: OpenSolaris talk at Debconf
Monday, December 04, 2006
Debian: Tattoo
Unless something very surprising happens, this is the tattoo I will not be getting. Alas. There's still around sixteen hours until it's no longer December 4th anywhere, but it's not going to be enough.
Thursday, November 02, 2006
Debian: Something Positive and vocal minorities
R.K. Mulholland, author of Something Positive, one of my favorite web comics, writes something that seems pretty relevant to Debian:
People assume most Debian developers are heavy-handed, pushy, intolerant bigots bent of dominating any other culture or idea and supplanting it with their own whims because, for the most part, the ones who speak up the most ARE heavy-handed, pushy, intolerant bigots bent on dominating any other culture or idea and supplanting it with their own whims. It sucks. It's horrible. And it's the what everyone of any faith, political idea, or lifestyle has to deal with. People always focus on the loud minority who ruins everything. And like any other group, the only way you can combat this is making your views and, in this case, your kindness and actual testimony louder than the hateful prattle of those hurting your beliefs.
Mulholland actually writes about Christians, but I took the liberty of substituting the words "Debian developers" instead.
I wonder if I should reconsider my policy of shutting up and going away when people start quarreling or otherwise behaving badly inside Debian. Perhaps participating more actively in such a situation would be helpful, if only to make it clear that those most vocal do not always represent the majority.
Mostly such participation should be to do constructive things: offering solutions to technical problems, pointing out good things others do.
Sometimes it would have to be to help Debian make some of the very difficult decisions it needs to do. For example, what should the project do in the case of Sven Luther? This is a good example of a problem that Debian as a project is very ill equipped to handle.
I'm not sure I will do anything about this, but now that it's two hours past midnight, I feel I should. When I wake up, I expect to regret this.
Monday, October 30, 2006
Debian: BSP @ Helsinki
We're going to have a little Bug Squashing Party in Helsinki, on the 11th and 12th of November. See the wiki page for more information. The location is still open: we have a tentative place, but it's not ideal, so we're looking for something better. If you can offer some place, please mail me, thanks.
We will have the BSP in any case, so if you're interested in coming, start making your plans now.
Friday, October 13, 2006
Debian: A discussion wiki?
Mailing list discussions, especially about controversial topics, can become very high volume, and tempers easily get out of control. I wonder if it would be easier to conduct a civil discussion on controversial issues if it were done on a wiki page, with an explicit policy of trying to achieve the kind of neutral point of view wikipedia tries to achieve, and with edits being anonymous? The goal would be to write, in anonymous collaboration, a document that covers all the important facts and opinions on a given topic.
It might be good to try it, for some particular discussions. It might fail, but it might not. Perhaps the next proposal for a GR could be done this way.
(I think someone mentioned something like this some time ago, somewhere.)
Wednesday, October 11, 2006
Debian: Debian sources in bzr
Many moons ago I thought it might be nifty for my work on Debian QA to have an easy way to see what has changes in each version of a Debian package. I wrote a little script that built a bzr branch for each package, and imported each new version in my mirror. Unfortunately, there were some problems, and I didn't have the patience then to fix them.
Last weekend I finished the script (despite not doing any Debian QA work anymore), and set it running. Today it finished. There were still some problems: 88 packages failed, due to problems in bzr. I've reported them to the bzr mailing list.
The run took about three full days, on an machine with a 2 GHz AMD64 cpu (in 64-bit mode), 1 GB of RAM, and two 80 gigabyte hard disks in striping mode. It would've gone faster, but I ran out of disk space a couple of times, and it took me hours to wake up and notice.
Disk space usage is now about 90 gigabytes, but that's with most branches' working files removed, to save disk space (i.e., only the .bzr directory and contents in most branches).
Note that the size shouldn't grow very quickly. Most new versions only change some files, and only parts of each file. Version control systems are good at keeping only the changes. I'm pretty sure 200 gigabytes would last for a long time. Bandwidth and disk I/O might be more limiting, if we wanted to have this as a service open to everyone.
I don't know if bzr is the best vehicle for this; perhaps a huge Subversion repository would work better. My instinct says that a distributed version control system would work better, but I'm sure a centralized one would work, too. Whatever the system, it might be helpful for QA work, and for making changes in many packages at once, to have something like this.
For QA work, it would make it easy to see what has changed in each version, or to find the version in which a certain change in a package was made.
For sweeping changes, this kind of a system should, I think, make it easier to automate the build and upload of packages that are changed.
I'm not, by the way, suggesting that this kind of a system would be used to do normal maintainer development. It would work by importing new uploads, not by having people commit to it directly.
Or perhaps such a system wouldn't have any use for Debian, I don't know. But at least the script was useful for stress testing bzr a bit, and finding a couple of bugs in it. So it wasn't a waste of time to finish it.
Debian: Eric Dorland is right
Sometimes it's good to show support to people who are under pressure for doing the right thing. Thus: I support Eric Dorland's decision to use the IceWeasel fork of Firefox in Debian. It would be nice if this weren't necessary, but in the reality that we actually live in, Eric made the right decision, and it is a good decision.
I value public perception, but I am firmly of the opinion, and I think history has proven me right, that the best way to get a very good reputation is to stick to doing the right thing. In the long run, this works better than choosing the easiest route to gain short term acceptability.
Security support and software freedom are more important, in the long run, than allowing people to remember only one name for a browser.
(I admit that I'm biased a bit, being an Epiphany user myself. I doubt that affects the thrust of my opinion.)
Tuesday, October 03, 2006
Debian: Joey Schulze is wrong
Martin "Joey" Schulze is interpreting my decision to spend some less time on Debian as being due to dunc-tank. He's wrong.
Joey, you're spreading false rumors. You could easily have checked the facts with me, but you chose not to. That is malicious. Kindly do not ever use my name to further your hate campaigns, thank you.
I'm reducing time spent on Debian rather than reducing time spent on other things so I could still do Debian things. One of the reasons for this is that it seems to me that a number of very vocal people in the project have collectively gone insane over the past few months.
As an example, proposing a GR as a reaction to dunc-tank was so much out of proportion that I can't understand how those who supported are capable of acting in a constructive manner at all. Either that or they seriously need a life.
I have some years ago developed an aversion to conflict. Rather than butting my head with insane people, I'll withdraw from mailing lists and reduce my participation in the project to maintaining the package that I care most about.
That's right, Joey, dunc-tank didn't drive me to this. You did.
I don't know if dunc-tank is a good thing or not, in the long run. I think it's a worthwhile experiment, and its future should be decided when the experiment has been done.
Another reason to reduce time spent on Debian is that I'm looking into starting a business. That can be quite time consuming.
Monday, October 02, 2006
Debian: Piuparts et al orphaned
Whee, that was fun. I orphaned three packages (liwc, piuparts, and publib), and asked for the removal of two more (python-licosmamo and lodju). The removed ones have no users (mostly not even myself), and the orphaned ones don't either, except piuparts.
I'm hoping someone will adopt piuparts. See #390754 before you do, though.
The reason for this evening's activities: I have more responsibilities than I have time for, so I'm trying to fix that by shedding everything I can. I'm not leaving Debian (I will even maintain a package), but I'm not expecting to put in a lot of effort into Debian development in the near future.
Next year we'll see if I can't arrange for more time for this again.
Sunday, September 03, 2006
Debian: A code of conduct
I've been unsubscribed from the major Debian mailing lists for about a week now. I'm feeling withdrawal symptoms from not spending hours reading e-mail, but they are subsiding. I think I'm now in a brief phase of clarity and big picture view: it's been long enough that I don't only see the last fifty mails and react to any annoyances in them, but also not so long that I have forgotten what actually happens. I want to make use of this phase to formulate a suggestion for a new code of conduct for Debian mailing lists.
- Shut up, unless you have something important to say. Don't chatter. If you must say something, keep it brief, to the point, crystal clear, and give references to you claims.
- Shut up: don't repeat arguments, not your own and not other people's.
- Get a life: you don't need to decide every detail, not everything needs to be done your way. If someone wants to do things their way, let them. If it turns out to be a mistake, well, they've learned something.
- Shut up already: insinuations, insults, name calling, character assassinations, all these are fine for the school yard or in modern office politics, but we're supposed to be having fun here.
The above is intentionally not all nice and sweet. My doctor forbade me to have anything to do with sugar.
Tuesday, August 15, 2006
Debian: Installation videos
In the "for those with free time looking for ways to spend it" department...
I think it would be cool if someone were to prepare a short video of how an etch installation happens, in time for the release. Should be easy enough for someone who understands how videos are made (I don't).
Another, related idea I've had is a video showing how Debian installation has developed over the years. Take the oldest Debian CD you can find, install it, and repeat for every newer release.
Wednesday, August 02, 2006
Debian: LowThresholdNmu at 102
The LowThresholdNmu wiki page is now up to 102 people. It's been mentioned a few times on debian-devel lately, which probably explains the sudden quick growth rate. It was dormant for a long time before that.
LowThresholdNmu is about keeping a list of maintainers who don't mind ifyou make a non-maintainer upload immediately, without the two weeks of minimal delay mandated by the Debian Developer's Reference.
Friday, July 28, 2006
Debian: Project Ummikko
How good is Linux as a tool for the uninitiated, really?
When journalists review Linux, they usually concentrate on the initial installation experience. Given their deadlines, that's logical: they don't often have time to spend months on using it, so installation is all they have time for.
I wanted to know how good Linux, or more specifically Debian with GNOME, is for the uninitiated, or more specifically, for someone who has been using Windows for a number of years, and switches to Linux. I'm specifically uninterested in the installation experience.
To see what it is like, I recruited a friend of mine, and gave her my old laptop with Linux pre-installed and pre-configured. She has agreed to try switching all her computer use to Linux, and tell me about any problems she has. We'll do this for several months, to make it realistic. Anyone can suffer through a week in a new computer environment.
She's now used Linux for a bit over a week. The initial session, when she tried out the new computer at my home, went pretty well, with only a couple of real problems. Here's an edited version of the notes I made:
Bringing up the network (the laptop is configured to use NetworkManager): She found the networking subfolder of the computer folder in GNOME: "Why does it say 'Windows Network'? And why is that empty?". Later: "Why does 'Network tools' not configure the network?".
She doesn't know if configuring network in Windows would be as bewildering, never having done it. She can't find anything useful about network configuration in the GNOME help system. Eventually I point out the Network Manager icon in the notification area.
She selects a wireless network to connect to and enters the WPA password I give her. She then gets the GNOME Keyring dialog and doesn't understand what it is, wondering why she needs to give the WPA password a second time.
She then proceeds to open some windows. "Minimization works, good." She is happy that there is a task bar at the bottom of the screen, and happens to find the "Show desktop" button there as well: "Oh, you can hide all the windows here if you have many."
She finds mplayer and thinks it looks OK. She comments that she doesn't really care what player she uses, she uses several under Windows, too, and all of them have quirks.
XChat has too many networks to choose from at startup. She's never had to choose an IRC network before, IRCnet being the default for Mirc (or the Mirc installation she has, anyway). She wonders why XChat didn't ask for a server to connect to after selecting the right network (XChat has a lot of servers configured for each network and chose one of them).
She continues to configure XChat: "Oh Lord, NO spell checking." She finds the color selector in XChat (the GNOME or GTK+ default one) to be very confusing. The "Nicks not to highlight on" setting is bewildering, does it mean that XChat highlights by default all nicknames, even for other users?
She'd like "shut up completely" setting for XChat sounds. Giving ops from a popup is intuitive. XChat in general seems intuitive to her.
Next, Bittorrent, using the GNOME torrent downloader. The .torrent file is saved directly to the desktop, which is good. The downloaded file goes there too, which is good, too. Seems intuitive enough, but doesn't seem to have very many settings: it would be nice to be able to prioritize different parts of a multi-file download. She also can't get it to continue a download after restarting the client (possibly related to multi-file torrents).
Next, OpenOffice.org. The Windows version doesn't split up into Base, Writer, Impress, etc, but finding the interesting one (Writer) is no problem. That Abiword was installed, too, was a bit confusing.
Totem: space doesn't play/pause (except in full screen mode). Sound volume control is a bit confusing, since it has to be done using multiple slidebars (master, pcm, etc) in the GNOME sound control dialog, and also in Totem.
After maximizing Totem, quitting it, restarting it, the window is now as big as the whole desktop (minus top and bottom panels), so maximizing and un-maximizing doesn't seem to have much effect, which is weird.
Other problems have surfaced since. The big one was that I had configured a simple firewall for her that didn't let anyone connect to her laptop, meaning that torrenting was not working very well. I use the same firewall settings on my own laptop, but since I mostly torrent for Debian's ISO images, and those have really fast seeders, I've never noticed that I don't torrent outward. Ah well.
She also doesn't like the GNOME torrent client very much. It lacks ways of monitoring and controlling the torrenting process that she cares about: seeder and peer counts especially, or (but less importantly) changing the order in which parts of a multi-file torrent are downloaded. We tried installing Azureus, but the version in Debian etch at the time seems quite broken.
Firefox seems to occasionally also work very badly for her, taking tens of seconds to load pages, but this seems to be a known bug that will be fixed in the next upstream version. We'll upgrade when we can, and hope that fixes it.
Firefox's default font size was too small. Same for the default window size. And sometimes, maximizing the window still doesn't make the contents become bigger (but it works under the Windows version of Firefox). I haven't seen this myself yet, but if I do and can replicate it, I'll file bugs.
Another problem that was due to my bad installation: I had forgotten to install acpid, so every time she booted, she got an error message saying "Can't access ACPI events in var/run/acpid.socket". Her exact words when reporting this were: "I don't want to know. Really, I don't. But, just in case you do."
That's it for now. I may write an updated report later, if there's any interest.
(For the curious, I'm intentionally not naming her, to let her try the experiment in peace, rather than getting her mailbox full of well-intentioned advice on things to try or do.)
Friday, July 14, 2006
Debian: The Debian Vacation Event
The Debian Project, in an inspired move to improve to reduce stress stemming from overwork, locked out its developers from debian.org machines. This experiment was a complete success. With no way to do uploads, or to read web logs on Planet Debian, Debian developers the world over had a very relaxing two days of vacation.
"Morale is up 1.3%", boasts Debian Project Leader Branden "aj" Robinson, adding "it only took four hours to unstick my finger from the Planet reload button, so that I could get up and have a shower".
Asked whether the project would recommend the same procedure for other free softare projects, Robinson replied, "You betcha". Open source mastodont Microsoft founder Bill Gates concurs. "We've been doing the same thing for years. We have an entire team devoted to keeping backdoors open for just this kind of opportunity."
Independent IT expert Lars Wirzenius jumps on the bandwagon. "Yes! A very good idea! I'll happily sell my services to anyone who wants to add a backdoor to their system. I'll make two for the price of one!".
Friday, July 07, 2006
Debian: Photo mosaics of Debian logos
Metapixel seems very cool.
The full size pictures megabytes in size. Sorry.
I made these within minutes of hearing about metapixel. They can certainly be improved, but I don't have the time for that, sorry. I'm just happy to have made this easily.
Wednesday, June 28, 2006
Debian: Re-qualification of Debian developers
The Debian New Maintainer process (NM) is well-known to be strict and tedious. It tests the skills, aptitudes, and attitudes of candidates in a number of areas, including technical, philosophical, and license interpreation. The process keeps the minimum level of competency of new maintainers at a reasonably high level.
We have, however, no process for ensuring that old farts don't stink.
Take myself for an example. I have been with Debian for over a decade, but I still find new surprises in things that are from the early days. Just recently, I learned about dch, which has existed since 1997 or before. This discover made my life much easier: I had grown tired of updating debian/changelog dates by hand, so they tended to be rather inexact. Now, when I do an upload, the changelog date is no longer a lie.
The problem is not that I am incapable of learning, or that I don't want to learn. It's just that I don't, unless I make an effort to do so. Given the small amount of free time I have, I tend to spend it on other things.
Most Debian developers probably keep up with most changes to policy, tools, procedures, best practices, and such, without anyone prodding them. However, during the past year and a half, when I've been doing quality assurance work, I've noticed that there seems to be a number of people who don't give any indication of current competence.
There's two approaches we can choose from to deal with this. We can educate, or we can re-test.
Education means writing documentation, announcing important changes, maybe giving IRC or video tutorials over the Internet, and so on. It is quite a bit of work, but if done properly, it would have quite an impact.
Re-testing means putting everyone through NM at regular intervals. Certainly not the entire NM, that would be way too annoying, but a quick slimmed down version would be possible. Something that ensures that every DD still has at least a minimal level of competence, but doesn't take more than an hour or two to do, unless one is a decade out of date.
There is of course the problem of what to do with people who fail the test. The simple approach would be to give them, say, two months of time to get up to date, and then they are re-tested, and if that too fails, they're retired.
I'm not sure whether we should do either. Perhaps we could try both.
Monday, June 19, 2006
Debian: Packaging tutorial (again)
I gave my Debian packaging tutorial today. The Computer Science department of the University of Helsinki provided the space (a classroom with networking), for which I hereby offer grateful thanks.
There were fourteen students, and everyone made a package out of my hello world program (especially written for this tutorial). The slides used my liwc package as an example, and during the talk I noticed a couple of problems, which promptly resulted in a bug report. Excellent!
Nobody wanted to do a victory dance, people are too shy.
I've now given this tutorial twice: once for three of my friends privately, and once for a larger group. It only covers the very basics of creating packages, and there's much more to learn. Some day I might do a second part, and cover things like maintainer scripts, advanced dependencies, debhelper, pbuilder, and piuparts (the last three were only briefly touched upon today).
I might be willing to do the first part again, if there's enough interest. Not very soon, though, teaching is surprisingly exhausting and time-consuming. However, if you'd be interested, please do mail me (at liw@iki.fi).
Tuesday, June 13, 2006
Debian: Packaging tutorial/workshop
My Debian packaging tutorial will happen next Monday, June 19. The info page for this is at http://liw.iki.fi/liw/debian/school.html and you should monitor that page for updates.
This is a fairly short notice, sorry. I suck at organizing things.
Tuesday, April 25, 2006
Debian: Packaging tutorial clarification
I wrote a couple of weeks ago that it would be fun to organize a packaging tutorial this summer. It seems that a couple of people thought this would be a bit more than I intended, so let me clarify: this would be a one day event, HP is not sponsoring it apart from (hopefully) letting us use an auditorium or meeting room, and it's probably not worthwhile to travel from abroad to Finland just for this.
There has been a fair bit of interest within Finland, however, and I hope we can make this happen. Several people have offered to help. I guess the next step is to decide on a date. When I have news about that, I'll post it here, and then start announcing it in other places, too.
It would be cool if someone with suitable contacts could see if some (modest) sponsorship for travels within Finland could be arranged. Many interested people are not in the Helsinki area, so they'd have to take a train or plane to get here, and that can be expensive, if they're students. Free accomodation has already been promised by two of my friends who have a large apartment.
Sunday, April 16, 2006
Debian: Flames you never see
Sometimes there's e-mail that makes me quite angry. I then write a reply, and it is often a very angry reply. A flame. A scathing argument that annihilates the argument, persona, ancestry, future, and in fact entire existence of whoever angered me. Much of my best writing happens this way.
Nobody ever sees these e-mails, though. The flamees will never know how utterly, totally, excruciatingly helpless they would have been under the scalpel that is my e-mail. I'll know, and I'll be quite smug about it, too, sitting in a dark room with my laptop in my lap, giggling.
Not entirely unrelatedly: David Nusinow, you are owed a drink of your preference. No giggles for you, only respect and understanding for mistakes.
Wednesday, April 12, 2006
Debian: Packaging tutorial next summer in Finland?
I met someone from HP Finland yesterday and he gave me a tentative promise that HP would be willing to give its auditorium for free if I want to arrange a Debian packaging tutorial during the summer.
I've given such a tutorial to some friends, and it would be fun to do it again, if there's interest. The way I imagine it currently would be that there's a theoretical lecture first, say one hour, that covers the basics of packaging.
The second part is hands-on training, where everyone builds packages, and if they have problems, I and others will help.
Depending on how long we want to make this, we can then continue with more lectures, and maybe more hands-on stuff.
In my calendar, the weeks starting June 10 or June 17 would be ideal.
This would, of course, be completely free for participants, and open to everyone. If you would like to participate, either as a student or as a teacher, please drop me a note. Nothing is binding right now, I'm mostly just interested in how many people are interested.
Wednesday, March 15, 2006
Debian: Watch files, last time
Eric, I think you misunderstood what I actually said. I am in no way opposed to watch files, nor do I dislike them. In fact, I think they're quite nifty, and useful for many people.
I dislike the repeated complaints that so few people put them in their packages. I proposed a way to solve that, once and for all, without getting a thousand people to do something.
I also dislike putting information that can and does get out of date into places where it is hard to find and fix, instead of a centralized location. The copyright file contains information about where the package was downloaded from; the watch file tells where the current upstream version is. The latter needs updates, even when the package otherwise does not.
Here's a quick plan, for those who want better watch file coverage: start an Alioth project, with a Subversion repository for watch files missing from packages; make a patch to qa.debian.org/developer.php to use a watch file from the centralized repository if the package itself doesn't contain one; and finally advertise the new stuff and ask for interested volunteers to start submitting them, via Subversion or by e-mail.
For Alioth and Subversion feel free to substitute anything else you prefer, of course.
If someone does that, I'd be quite happy to write and submit watch files for all my own packages.
Monday, March 13, 2006
Debian: Why I don't make watch files
Eric Dorland writes about watch files, which are a way to keep track of whether there are new upstream versions of a package. He urges everyone to add them to their packages. I don't want to do that.
First, I'm also the upstream of most of my packages, so my need of them is small. When I'm not upstream, I keep track of what upstream does anyway, so I'm informed of new releases that way. I realize that watch files are not useful only for the package maintainer, but also other interested parties, but, hey, I'm lazy, so I need some incentive apart from "some people think they're cool" before I take on a duty to maintain yet another aspect related to packaging.
Second, I don't think watch files belong in the package. If upstream moves to a new domain, for example, the watch file needs to be updated. If it is in the package, that needs the package needs to be updated. I'd rather see watch files kept in a central server so that the package doesn't need to be changed in this situation. This would also avoid the need of having the package maintainer co-operate.
Thus, I propose that those seriously interested in watch files create a "watch.debian.net" service, which keeps watch files in a centralized location, and allows them to be maintained in a wiki-like fashion.
Wednesday, March 08, 2006
Debian: NMU / rc bug fixing checklist
A year ago, when I made several non-maintainer uploads for release critical bugs, I made a checklist for myself. Here's an updated version of it. Comments welcome.
- Check what the package description says that the software does.
- Read bug report.
- Attempt to reproduce bug. If this fails, send note about it to the bug report and quit.
- Attempt to fix bug
- Consider urgency: low, medium, or high?
- Build fixed package. Run lintian, linda, and piuparts on it. Verify that bug is fixed. Be really, really sure it has been fixed and that no new bugs have been created.
- If bug is not yet in bug tracking system, send it there.
- Notify maintainer of upcoming NMU.
- Subscribe to the package's bugs via packages.qa.debian.org.
- Upload to DELAYED/n or wait for n days and do upload then, unless the maintainer has reacted and told you not to.
We're currently on 0-day NMU mode for release critical bugs that have been open for over a week. For those, doing an immediate upload in the last step should be fine.
For people who've added themselves to the LowThresholdNmu page in the wiki, a 0-day NMU is always acceptable.
Sunday, March 05, 2006
Debian: A big momentum hug
Josselin Mouette thinks name-calling makes his point. I quite disagree. His approach does nothing to make Debian better; in fact, it only serves to reduce many people's interest in working on Debian at all.
David's point about development momentum is very good. I completely agree with it. I sort of started on this line of thought in my DPL platform draft, although David took it further and said it better.
Momentum can only be increased if the people involved are having fun; they will have fun if momentum is increased. If something prevents development from gathering momentum, or saps the fun out of working on Debian in some other way, things fall apart. For quite a number of people, flame wars are fun suckers. "Stop energy" sounds like a good term to me.
I'm talking about flame wars. I'm not talking about discussion, debate, or disagreement. It's perfectly possible to have those without getting actively aggressive, passively aggressive, repeating your opinion 75 times per day, resorting to name calling, or employing any of the other charming tricks that Debian mailing lists see.
That's enough talk, and enough attention paid to bumps in the road. Time to enhance my tools so that I can find and fix all the remaining bugs in Debian.
Friday, March 03, 2006
Debian: D-W Python tutorial
In February, I have an online IRC tutorial for Python on #debian-women. I finally managed to write the written version of it, and it is now on the Debian-Women wiki, thanks to Angelina Carlton.
Monday, February 27, 2006
Debian: FOSDEM slides up
I'm back from FOSDEM 2006. I had a very nice time, and will be writing a fuller entry about that later; this is entry is to mention that I've made my slides available. I'll be giving an updated version of the talk at Debconf6 in Mexico, so beware if you fear spoilers.
Saturday, February 11, 2006
Debian: Device driver check page
It has been a while since kmuto advertised this: Debian GNU/Linux device driver check page. It is time to advertise it again, I think.
Basically, you paste the output of "lspci -n", and it tells you which hardware on your PCI bus is supported, and by which driver. Very, very cool, and makes it much easier to see what to buy (assuming you can find a store that lets you, say, boot a machine with a live cd).
Many, many thanks to kmuto!
Monday, February 06, 2006
Debian: What kind of DPL?
The nomination period for the Debian Project Leader is on again. This means that the Finnish winter is at its worst, and indeed, as I write this, it is -22 degrees Celsius outside. The sun went down about six hours ago; I woke up quite late, so I only saw half the sunset.
Back in November, while vacationing, I spent some time thinking about what the role of the DPL is, and now seems a good time to say it. The actual work of developing and maintaining Debian is done by package maintainers, translators, a handful of infrastructure teams or other special purpose teams, bug reporters, and others.
It is not the job of the DPL (in their role as DPL) to take charge of the actual development: the DPL is not expected to administer debian.org machines, to fix RC bugs themselves, or to make decisions about release management. Instead, the DPL's job is to help everyone else do those things.
If some part of project isn't working well due to resource shortage, or personality conflicts, or other issues, it is ultimately the DPL who needs to facilitate, mediate, or otherwise deal with it. This is not uniquely the DPL's job: any Debian member could step into a situation and help, but the project does need someone whose job it is to do that if no-one else will or succeeds.
Another important job of the leader (again not uniquely) is to provide inspiration. Our leaders in the past few years have provided fairly little of that. I would like us to have a DPL that inspires the project into setting and achieving goals that make us happy and make Debian the best operating system ever.
The important thing is to inspire, not to force, cajole, or otherwise unilaterally decide. Not quite sure now how that should happen. Perhaps the Finnish military saying that "leading is best done at the front" is applicable: an inspiring DPL is one who by his own work, and his own behavior, shows by example what a good, productive member of the Debian development community is like.
A third important job of the leader is to be the project's public face to the rest of humanity. Again, not uniquely, we have other members who are often prominently in the public eye, such as release managers or security people, but the DPL is the main such public face.
And finally, the fourth important job of the leader is to do the tasks assigned to him in the Debian Constitution. These are not daily tasks, but they're important, and these, at least, are uniquely the DPL's domain.
Wednesday, January 18, 2006
Debian: One more about the OpenSolaris talk at Debconf6
Alvaro Lopez Ortega comments on my explanation of why I don't want the OpenSolaris panel talk at Debconf6. He misses the point: I am not objecting to OpenSolaris itself, but to having a talk about it at Debconf6.
From my entry: "I [...] questioned the fact that Debconf6 will have a talk on OpenSolaris, when there are good Debian related talks rejected." I think that for a Debian development conference, having a talk about Debian is much, much more important than discussing OpenSolaris, or even co-operation between Debian and OpenSolaris. That is the core of my objection: OpenSolaris is not about Debian, and the talk is crowding out a talk about Debian.
As a smaller issue, I do also happen to dislike the OpenSolaris license (the CDDL), and this makes me dislike having the OpenSolaris talk (instead of a Debian one) even more. I have sufficient grounds for disliking it in the fact that it is Yet Another License. More importantly, it seems to be incompatible with the GPL, which causes all sorts of unpleasant complications if Debian wanted to use OpenSolaris code. Further, it seems unclear that the CDDL fills the requirements of the Debian Free Software Guidelines. The result: there is little room for co-operation between Debian and OpenSolaris. This doesn't mean OpenSolaris is evil or that it needs to be shunned. I'm perfectly happy with non-free software, but not in the Debian context.
The license issue can, however, be disregarded completely, when arguing about having this talk at Debconf6, as far as I care. I want to see a Debian conference concentrate on making Debian better, and not on making OpenSolaris better. If there were free slots in the conference programme, I wouldn't mind, but there aren't. All slots are full, and Debian specific talks have been rejected in favor of the OpenSolaris talk. That is what irks me.
Note also that I'm not criticizing the people who want to give this talk (or hold the panel, or whatever), only the Debconf6 talks committee. And I did that in private, I didn't drag it into public.
Wednesday, January 11, 2006
Debian: On using phones
Martin Krafft asks why some people don't like telephones. I'm one such person.
Telephones are error-prone, low-bandwidth and high latency communication media that still require real-time response. I like having a conversation face to face, but using a telephone cuts out almost all the bandwidth from that, so that you can only rely on voice, and not even the full spectrum of that. What with a limited spectrum of frequences, low sound volume even at the highest setting (I have bad hearing), strange accents, and generally abysmal sound quality (background noise makes it almost impossible to hear what the other person is saying), it takes a lot of time to get anything settled over the phone.
IRC, for example, is in many ways similar, but it differs from a telephone in two different aspects: you don't need to react within seconds, and messages get through loud and clear (well, big-fonted and clear). Even if a telephone call may be shorter than an IRC discussion, it requires much more effort to happen, and on the whole is not as productive.
This doesn't mean I'd refuse to discuss something over the phone, but I'd really, really rather not.
Thursday, January 05, 2006
Debian: OpenSolaris talk at Debconf
Alexander Schmel writes in his web log:
Update: Small correction: We got some feedback. Liw raised some concerns. His mail was answered 8 minutes after we received it by a committee member. Since he didn't answered I guess he is satisfied by the answer or at least doesn't feel very strong about that point.
To clarify: On December 27, I mailed the talks committee and questioned the fact that Debconf6 will have a talk on OpenSolaris, when there are good Debian related talks rejected. I have received their response, and I understand their reasoning. I strongly disagree that their reasons are sufficient to approve the talk. I haven't responded yet is because I'm thinking about the appropriate way to do that. Celebrating the new year also intruded.
Silence does not necessarily signify assent.