Lars Wirzenius: March, 2006
Contents
- March 20: PyGTK tutorial
- March 15: Watch files, last time
- March 14: Publib, the library that wouldn't die
- March 13: Why I don't make watch files
- March 08: NMU / rc bug fixing checklist
- March 06: "Producing open source software" by Karl Fogel
- March 05: A big momentum hug, Mice hands
- March 03: A blurb, D-W Python tutorial
Monday, March 20, 2006
Travel report: PyGTK tutorial
I gave a talk to the Finnish Unix User's Group about PyGTK programming (see also examples). It seemed to go fairly well, although one hour is certainly not enough to do more than scratch the surface a teeny bit.
This happened at FUUG's annual cruise, which this time went to Tallinn, Estonia. The service on the ship was not the bestest ever, but otherwise it was pretty nice. I had a cabin on my own, which was much nicer than the usual style of putting four people into a sardine jar.
One of the things that came up was the fact that while there is fairly much interest in arranging a big happening in Finland next fall in honor of Linux's 15th birthday, there seems to be a severe lack a head organizer. This is sad.
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.
Tuesday, March 14, 2006
Random hacks: Publib, the library that wouldn't die
Many years ago, when I was young and arrogant, I wrote a library of more or less useful C functions, some of which I hoped would eventually migrate to the standard C library. I also created a build system for libraries that I hoped would become popular. Well, neither thing happened, as every sensible person would have predicted.
The library is packaged in Debian as publib-dev, and it is used by a couple of other packages.
I've been meaning to kill it off for a couple of years now, but I haven't yet. Lately, I've received some feedback about it, and even a bug report. This makes me think that perhaps it is of some use to people, and in that case it would be a shame to kill it.
So, I am wondering what to do. I don't often write C programs that would benefit from the functions in publib-dev anymore. The library needs serious code review and the addition of unit testing, to make sure its various parts actually work. Some parts might need to be chopped off, because they aren't useful anymore (if they ever were).
It should also be made into a shared library. I didn't make one originally, since shared libraries were a thing that were suspiciously new in Linux at the time (or perhaps they didn't yet exist at all). At some point I figured I'd wait until the shared library situation in Linux settled down a bit, before learning how to create them. And then the whole ELF thing happened, so I decided to wait for a while more.
I'm not sure I have the time to do all that by myself. So, a request: if you think you would like to use publib-dev in the future, and maybe even participate in its maintenance, and in making it into a shared library, please mail me at liw@iki.fi.
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.
Monday, March 06, 2006
Review: "Producing open source software" by Karl Fogel
Karl Fogel's Producing open source software: how to run a successful free software project covers many of the important aspects of free software projects, and concentrates on the parts that are different from, say, traditional in-house development projects.
The book covers technical aspects like mailing lists, bug trackers, version control systems, and other infrastructure necessary for a project to survive. It also covers more social aspects, such as how to deal with flames, forking, or how to employ developers for free software projects.
The book is written well, and is a light, fairly quick read.
Those of us who have participated in free software for a long time can find the book as a nice summary of things that have been learned over the years. Those newer to free software development may find many new things to learn. Most of us will find something to think about.
Despite the level of detail Fogel gets into, the book obviously only scratches the surface. Free software development is such a vast new territory that it is not realistic for one book to cover all of it. For example, this book does not cover conferences and other face-to-face meetings, which are important for keeping the community of free software developers alive.
With the caveat that it doesn't make further volumes on this topic unnecessary, Fogel's book really is worth the time it takes to read it. Recommended.
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.
Random thought: Mice hands
Jordi writes about the lack of left-handed mice. I feel his pain, having been there.
Many years ago, I decided to start using a mouse with my left hand, even though I'm primarily right-handed. The basic reason was that with a normal keyboard, you have to move your hand a long way over the cursor keys and the numeric keypad to get to the mouse. With the left hand, it's just there, a few centimeters away. Much nicer.
The fact that I could use cursor keys or the keypad while using the mouse was an added benefit.
About ten percent of all people are left-handed, and that's a pretty hefty piece of the entire market. If I were a mouse maker, I'd do my best to satisfy it. If I was a radical type of person, I'd suggest a letter writing campaign.
Incidentally, it only took me a couple of days to switch mouse hands, but I never got as quick and precise with my left hand as I was with my right hand. I don't think it is acceptable to tell left-handed people to just switch to using a mouse with their right hand. (These days, I only use my laptop's touchpad.)
Friday, March 03, 2006
Hedgehog Lisp: A blurb
I found a document I started to write a couple of years ago about Hedgehog. I might as well put it on the web, I guess. Hedgehog blurb (expanded a lot) was originally written as an exercise to see how much crappy text I can produce per hour. Turns out, quite a lot. It has since been fixed a bit, but it's still highly suspicious. Probably not interesting to anyone who isn't interested in Hedgehog Lisp.
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.