Our brunch yesterday went super-well. We had about 15 people over, which was far too many for our supposedly mellow evening. But it was great -- we got to catch up with a lot of folks I've been missing over the holidays and haven't gotten to see. I hadn't seen Lucinda Catchlove much for a few months, and Heather Kelley and Damian DiFede made an appearance, too. We got to see John Usher, who's off to do weird things to people's ears at the Consumer Electronics Show in Las Vegas. Niko came with friend Johanie, who made some great black-bean brownies; DJ Ghostbeard was still feeling ill from NYE; and Meg showed off her deep purple hockey bruises. It was also nice to have some new friends come, too. I've been wanting to hang out with MC Turgeon, one of the most experienced bloggers in Quebec, founder of me dia and toiles-du-Web, since we met last year at South by Southwest. She and her partner Chris came over with a nice bottle of wine and got to know everyone there. Actually, she knew a lot of the people already -- she and Anne-Marie had met at Mutek, for example. When Patti came in, she said, "Oh, yeah, I know M-C. We do a lot of panels together." Ah, the panel circuit. Altogether a really good time. Probably the only downside is that our oven was really dirty, and while I was making quiches and roasted potatoes I smoked up the entire house. But it cleared pretty quickly, and with the nice weather we're having, I could even have the kitchen door open to clear the smoke. Unheard of! tags: bruncher mcturgeon montreal cooking

Making a point Speaking of unseasonably warm weather, the Green Party of Canada held a picnic and ice cream social on Mount Royal last Saturday, which would have a couple of feet of snow on it in a regular year. The subject of discussion? Climate change, of course. I dunno -- clever move, but do they have to rub it in? tags: green party picnic climate change

Shameless plugs My friend Allegra has started a great new blog, Sucking-stones. She's got a really good voice and it's now in circulation as one of the blogs I read each morning. Also, my friend Anne-Marie Bergeron has her first travel TV show on 33mag tomorrow. She's got a four-part series on her trip to Iceland which they're going to show. It's in French, but her husband Jeff only cusses in English, so that's probably what you'll hear when they're climbing glaciers and lava floes. Did that get everyone? I hope so. You know what they say: You can plug your friends, and you can plug your ears, but you can't plug your friends' ears. Or something. tags: allegra sucking-stones annemarie jeff 33mag

Chix I was just reading Angela Beesley's end-of-year blog post and realized that I'd missed the establishment of WikiChix. It's a new organization for female wiki participants, in the great tradition *Chix tradition of Linux Chix or Debian Women. All the more galling is that two other blogs I regularly read also covered the new group. Joseph Reagle made a note about gendered spaces and the role they play in any movement (like Open Content and wikis). Biella blogged about his bloggage and put some social-science twist that was a little hard for me to follow. In any event, good luck to WikiChix. I find clubs extremely fun and useful and by nature exclusionary, and nothing to get worked up about. Of course, as one of the two founding members of the Maldekstrulaj Vegeteranaj Esperantistaj Linuxamantoj (Left-handed Vegetarian Esperantist Linux-users Club), I'd probably be pretty hypocritical calling anyone else exclusionary. tags: wikichix wiki angela beesley joseph reagle biella coleman clubs

Quadmachine is a virtual instruction set architecture, designed mainly as a target for simple educational compilers. It has the following noteworthy features:

• RISC design
• word size 64 bits
• address size 64 bits (theoretical maximum memory size 16 exabytes)
• all memory access is in word units
• 65534 general-purpose 64-bit registers
• 2 additional special-purpose 64-bit registers
• a variant of the “register windows” technique with automatic spilling

All of these, except for the preposterously large register file, are more or less realistic for a 64-bit RISC design. The size of the register file is intended to trivialize register allocation in compilers. This is the second Quadmachine design. Main differences from the previous design are a move to a load-store RISC architecture and the upgrade of the word size to 64 bits. There is a software realization of the Quadmachine architecture, with a graphical debug console. It is written in Java for portability; speed was not an implementation concern. Read more

I am deeply missing a real wiki.debian.org/Hardware page. The current one is a joke. It would be nice to have something in the style of the Gentoo hardware page with nice pages which show what works and what doesn't.

I know about the Debian GNU/Linux device driver check page which is a good start, but:

• in most places (installation reports in and out of Debian) you will not see lspci -n output
• there is more to it than lspci (think lsusb, think stuff behind new/strange/uncommon buses - like the sound chips on some Apple ppc based machines)
• you need a running linux system (a live CD can be used for the test), but:
• Debian's live CD is in its infancy (I know, Knoppix should do fine)
• most live CD-s are i386 only (it doesn't matter that much, since amd64 machine should work with i386 live CDs)
  
• most places where you can buy hardware from:
• either they don't have the hardware in stock,
• either want an answer immediately,
• or they don't allow you to access the machine
• (I think) the database is outdated and people are not adding stuff to it
  
• there is no way to make a search based on the product name of the whole system and/or the component

Current situation (bad stuff)

wiki.debian.org/Hardware is a joke. For example, I was expecting to see a Network compatibility list, but instead I see some useless info.

What annoys me the most in this matter are dead links or links to dead/inactive projects.

Information is scattered all over the place (redirects and directories can help), is mixed/ungroupped, or is outdated.

Current situation (good stuff)

The information partly exists. Probably, in time, the wiki will be cleaned up, but until then you have to dig for the information.

There are plenty of sites and pages with information, but, still, you need to weed out the old/irrelevant stuff.

What to do about it

Before you say anything, no, there is no need for yet another Linux compatibility list project.

Ideas:

• contribute to the wiki
• add a wiki page for every machine you installed under Hardware/Compatibility/ Laptop,Desktop,Misc /$PRODUCTNAME (would it make sense to have it under Hardware/Compatibility/ Laptop,Desktop,Misc /$PRODUCTNAME/$DIST ?); link your page to the installation-report (you did fill an installation report for every installation you did, didn't you?)
  
• reorganize pages with directories (as proposed above)
  
• remove dead llinks
• add redirects for pages that just say "See foo"
  
• unify pages that contain almost the same information
  
• automatically make a wiki page for each (successful and unsuccessful) Debian installation-report based on the machine type (would need some logic to weed out the home made systems) - but only select the success/fail rate based on strictly hardware issues
• help Kenshi with his efforts for better hardware support

Update: Justin told me about the Ubuntu Laptop Testing Team project which is kind of nice. There is also a scraper script which was supposed to help making queries like "info about laptop X" and "which laptops have these features", but that script didn't work for me.

[Video] [Lyrics]

I know they re all thinkin I m so white & nerdy
Think I m just too white & nerdy...

Since I was a teenager I have always wanted to be big (read fat), black, and have a great big black voice, but I m just too white & nerdy... I wish I could one time sing this dressed in a red, long, satin night dress, looking just like a big, black Diva.

:)

As part of my work on Xen I've been playing with Xephyr (a replacement for Xnest). My plan is to use Xen instances for running different versions of desktop environments. You can't just ssh -X to a Xen image and run things. One problem is that some programs such as Firefox do strange things to try and ensure that you only have one instance running. Another problem is with security, the X11 security extensions don't seem to do much good. A quick test indicates that a ssh -X session can't copy the window contents of a ssh -Y session, but can copy the contents of all windows run in the KDE environment. So this extension to X (and the matching ssh support) seem to do little good.

One thing I want to do is to have a Xen image for running Firefox with risky extenstions such as Flash and keep it separate from my main desktop for security and managability.

Xephyr :1 -auth ~/.Xauth-Xephyr -reset -terminate -screen 1280x1024

My plan is to use a command such as the above to run the virtual screen. That means to have a screen resolution of 1280x1024, to terminate the X server when the last client exits (both the -reset and the -terminate options are required for this), to be display :1 and listen with TCP (the default), and to use an authority file named ~/.Xauth-Xephyr.

xauth generate :1 .

The first problem is how to generate the auth file, the xauth utility is documented as doing it via the above command. But this really connects to a running X server and copies the auth data from it.

The solution (as pointed out to me by Dr. Brian May) is to be found in the startx script which solves this problem. The way to do it is to use the add :1 . $COOKIE command in xauth to create the auth file used by the X server, and to generate the cookie with the mcookie program.

In ~/.ssh/config:
Host server
SendEnv DISPLAY

In /etc/ssh/sshd_config:
AcceptEnv DISPLAY

The next requirement is to tell the remote machine (which incidentally doesn't need to be a Xen virtual machine, it can be any untrusted host that contains X applications you want to run) which display to use. The first thing to do is to ssh to the machine in question and run the xauth program to add the same cookie as is used for the X server. Then the DISPLAY environment variable can be sent across the link by setting the ~/.ssh/config file at the client end to have the above settings (where server is the name of the host we will connect to via SSH) and in the sshd_config file on the server have the line AcceptEnv DISPLAY to accept the DISPLAY environment variable. It would have been a little easier to configure if I had added the auth entry to the main ~/.Xauthority file and used the command DISPLAY=:1 ssh -X server, this would be the desired configuration when operating over an untrusted network. But when talking to a local Xen instance it gives better performance to not encrypt the X data.

The following script will generate an xauth entry, run a 1280x1024 resolution Xephyr session, and connect to the root account on machine server and run the twm window manager. Xephyr will exit when all X applications end. Note that you probably want to use passwordless authentication on the server as typing a password twice to start the session would be a drag.

#!/bin/sh

COOKIE= mcookie
FILE=~/.Xauth-Xephyr
rm -f $FILE
#echo "add 10.1.0.1:1 . $COOKIE" xauth
ssh root@server "echo \"add 10.1.0.1:1 . $COOKIE\" xauth"
echo "add :1 . $COOKIE" xauth -f $FILE
Xephyr :1 -auth $FILE -reset -terminate -screen 1280x1024 $* &
DISPLAY=10.1.0.1:1 ssh root@server twm
wait

I'm finally releasing version 0.1 of my Flickr library, flickrpc. The name is actually misleading, and I should change it for 1.0, as the class name is flickrest and the transport protocol is HTTP/REST, not XML-RPC (as was the original plan, thus the name). This library is written in Python and uses Twisted.

Why another Flickr library?

Because Postr required it. All of the existing libraries that I know of are blocking (I used to use Beej's flickrapi, which was based upon Michele Campeotto's flickrclient), which makes using them in GUI applications painful. Early versions of Postr used threads so that uploading could be done in the background without blocking the UI, but as Postr makes more calls to Flickr whilst being used interactively these threads will become a maintaince nightmare. By using Twisted all of the network operations are handled in the main loop, and I can write callback-based network code just like I write callback-based UI code.

Why Twisted?

Because it works, and is popular. If someone has a HTTP client library that integrated into the GLib mainloop and will expose callbacks when operations complete, please tell me. I love what Twisted gives me, but at the end of the day if there is a simplier solution, I'll consider it.

Sounds excellent! Where can I get it?

There is a tarball of 0.1 available here: flickrpc-0.1.tar.gz. If you want to track the latest development, or contribute patches, there is also a Bazaar archive.

I dived through the list of open RC issues, and found some without any (real) activity for at least 20 days. Please remember: If we want to release Etch, we need to get rid of any such bug prior to release.

• libglide2: Reproducible segmentation fault with Voodoo2: Latest info is from December 1st that a driver needs forward porting
• initramfs-tools: [powerpc64] i-t tries to mount RAID/LVM stuff before the disk are up -> unbootable: Last mail from December 11st with suggestions from Sven
• libmail-mboxparser-perl: FTBFS: build times out during test (t/3_while): Possible workaround already in the bug log
• lvm2: several issues with devmapper devices: The maintainer didn't care to comment at all until now
• parted: NTFS (partition) not recreated correctly after resize:incorrect start sector: lots of discussions on December 16th, quiet since then

Amita June is reaching a point in her life where it's time for us to start weaning her from breastfeeding. Most parents do this much earlier, if they breastfeed at all, but we've been devotees of attachment parenting for a while, and we wanted to give her as much time nursing as possible. But at 15 months, she's ready to start doing things like sleep through the night on her own, drink only cow's milk, and be a little more independent. So, this month we're starting to do some night weaning. What does this mean? First of all, Maj is no longer nursing the baby to bed. She now is doing the main pre-sleep prep work (a bath), does a short nursing period, and then hands the baby off to me for some reading, songs, and walking down to sleep. This will gradually move into fewer, shorter nursings before sleep, and ultimately to none. Once that connection has been broken, I think the main point of nursing will be occasional comfort nursing during the day. Gradually, that will fade out. And then there will be none. It's kind of exciting to be the Primary Sleep Guy for the baby. We're re-connecting in a way that we haven't in a while -- I was only putting her to bed occasionally for a quite a while. It's also been pretty successful so far, which has been good. tags: amitajune weaning sleep parenting babies

Souper Bruncher When Maj and I first moved to Montreal, we had help from some friends who we'd known from before. After we moved into our apartment, we invited them all over for dinner to say thanks. In order to get to know people in our new hometown, we also asked each person to bring someone we didn't know, so we could make new friends. The event was so successful, and we met so many new people, that we made it a regular occasion. For almost three years, every Tuesday night we invited friends over to our home for dinner (or souper in Quebecois French), with an open invitation to meet new friends and interesting people. It was a great way to meet interesting folks in Montreal, and most of our best friends here we met through these dinners. We were even profiled in Elle Quebec as a model for how to make new friends. But when the baby was born, we just couldn't manage to organize dinners any more every week. Cooking for 20+ people isn't that expensive, especially since we're pescevegetarians and that kind of food just isn't that costly. But it does take a lot of time and energy, and with a newborn baby we just didn't have either. Now, with Amita a little more than a year old, we're trying to start up our regular home parties on a more manageable scale. We're doing brunch at our house on Sunday afternoons around 3PM, with a much smaller list of invitees, requests for RSVPs, and a clear indication that the event only goes until bedtime. (Our Tuesday night dinners would occasionally stretch until dawn.) It seems to be working pretty well; we've had a lot of fun at the last couple of brunches we've had. And brunch is a much more laid-back meal than a dinner party, anyways. (Although John Usher asks incredulously, "By what stretch of the imagination is 3PM between breakfast and lunch?") I'm looking forward to our next brunch (tomorrow) a lot, and I hope to get many more friends over to our home in the next few months of Sundays. tags: brunch montreal making friends souper bruncher

While the next debian release is being prepared it is not a good idea to upload new packages, so I'm trying to use the holiday to 'look across the fence'. For starters I've gotten me an iMac and so far I like Mac OS X. It is an immense improvement over Windows and a pretty good alternative to KDE from my point of view. I'm still a bit lost with accelerators and in-program window movement but it is nice to have another environment to play with.

And on that machine I'll try to play with sbcl, openmcl and f-script. But so far I'm been busy using iMovie to convert our DV tapes into DVD's.

(continuing with clearing the blogging backlog) Four days after returning home to the US from the trip to Australia, I was at it again, flying the other way around the world. In hindsight, this was totally insane, but I'd expressed interest in going much earlier in the year, I think before we'd organised to visit Australia. I flew to Madrid, via Philadelphia. I've said it before, but I'll say it again, Philadelphia International is a very nice airport. It's the first time I've flown across the United States, and it really is a long way. Just like Brisbane to Perth, it's a long time on a plane for staying in the same country. Arriving in Madrid, entering the country was extremely straightforward, as I've also said previously, the immigration guy barely looked at my passport long enough to open it and find a page to stamp. It was my first time in a country that didn't speak English and wasn't terribly bilingual. Fortunately the airport was signed in English as well as Spanish, and the information/assistance people all seemed to be able to speak English. I arrived in Terminal 1, and the European contingent were mostly arriving at Terminal 4, which is essentially a completely separate airport, a short shuttle bus ride away. My flight arrived in the morning, and I had about 4 or 5 hours to kill before the first of the European contingent rocked up. It was tempting to get a train or taxi into Madrid and have a bit of an explore, but I really didn't want to risk not getting back in time, so I just loitered around Terminal 4 for the time. The highlight of the waiting was I bumped into Doug Foster, who I used to work with a SecureNet in Canberra, disembarking a flight from London (where he's now working). It really is a small world. After everyone turned up, we got on a bus and headed for Badajoz, a mere 5 hour bus ride away. We didn't get away until about 7pm, so by the time we hit the road, it was dark, so there wasn't a lot to see. We arrived at Badajoz around midnight, and made a short walk to the hotel and had a late dinner and hit the sack. Unfortunately with all my travelling in the three weeks, I'd managed to come down with a cold, which started manifesting itself pretty much from the moment I got to Badajoz, so I started to feel increasingly suboptimal as the week wore on. Badajoz itself is an incredible little city. It's just like what I envisaged an old European city to be: narrow winding streets. It had a funny effect on me. I'd alternate between finding it really quaint, and incredibly claustrophobic (and I'm not usually the claustrophobic type). After doing a bit of self-analysis, I think the problem was the lack of sky. With so many buildings crammed in together and the narrow streets, the amount of sky you got to see was minimal. Definitely no horizon. I felt more comfortable at night, in fact the place looked really awesome at night. Everything was lit up, I think especially so for Christmas, and everyone came out and walked around and did shopping. The other thing that, well, I noticed about the city was that it was wall to wall concrete (or bricks, or bitumen). The buildings all connected up, there were no gaps between them, and the sidewalk basically ran from the front edge of the building, to the kerb, then there was the road, and then the reverse, so it was a real concrete jungle. That said, it was pretty clean. the sidewalks were all swept, there was no rubbish in the gutters. By about the second day, my cold had driven me crazy (my nose was running incessantly) and I just wanted some pseudoephedrine to dry it up. I didn't have a clue how pharmacies operated, but fortunately I was able to get Miriam to tag along with me, who spoke English as well as Spanish. She'd never heard of pseudoephedrine before, but as soon as she said it to the pharmacist, he knew what it was and came back with some form of Nurofen (ibuprofen) that also had pseudoephedrine in it. I didn't really want or need the ibuprofen, but when sick in Spain, beggars can't be choosers, so I took it. I didn't feel that it did a great deal for me anyway. Getting home again was fun. Due to various peoples' flights, the bus was leaving at 6:30am, and that wouldn't get me back to Madrid the ideal 3 hours before departure, so I took a taxi with a few people who needed to be there earlier. It left Badajoz at midnight, and arrived at Madrid at about 4am, where I had to wait for about 5 hours before I could check in for my flight. I had a bit of fun leaving, which I've already written about, and was happy to get home late on Sunday night. My cold had gone to my chest by this stage and I had bronchitis, so I was just glad to get home and see a doctor on Monday. So now I can say I've been to Europe. It was a shame I didn't get to see Madrid itself. Next time. Update Photos from the trip are here

Well, Damog post about him wanting to visit Paris reminds me that I have to mention that the "Bubulle Hotel" located not that far from the city of Paris is always opened for Debian friends wanting to spend a few days here around and visit the Paris area. Definitely, my house is not the most convenient place to use as a starting point to visit the city (it's 30km south-west of the center town and needs 40 mins by train to be in Paris), but some already enjoyed it and I have room enough. So, don't be shy and just ring the bell if you happen to come around here...or plan to spend a few days in Paris before going to Debconf.

I’ve also started to look for the best plan to reach Edinburgh next June. I don’t think I’ll fly directly from Mexico City, since I want to visit Paris (in spite of my previous and only experience with CDG back in 2005 ) and then visit a nice friend in Bilbao. Then I could fly from there to Edinburgh or some place nearby with a cheap flights airline.
Quick searches throw an estimate of 1′150 USD for the trip MEX-JFK-CDG-JFK-MEX on Delta. Fortunately, I’ve started saving already, so I don’t get pressure on money once DebConf gets closer. I still don’t know anyway if this could be the best way to travel. I’ve been suggested, also, to travel from Canc n to Madrid through Air Europe, with the cost of ~515 , which is way more cheap than to fly to Paris, but I should also pay for the transportation from Mexico City to Canc n and from Madrid to Paris, if I really want to visit it, which I do. Anyway, the cheapest flight I could get directly to Edinburgh is ~1300 USD: MEX-ATL-EDI-ATL-MEX, with Delta too. Any suggestion on the matter is welcome and appreciated.

I have been asked for advice about long-term storage of documents. I decided to blog about it because my thoughts may be useful to others, and because if I get something wrong then surely people will correct me. ;)

Many organizations are looking at using computers for storing all documents. This gives savings on the costs of storing paper - the promise of the paperless office is being fulfilled. There are some potential issues about whether a signature in a PDF file that's scanned from paper is valid - but I guess it's the same as a signature on a FAX and everyone seems to accept FAXed contracts.

The technical problem is how to reliably store data long-term. The problem is that all modern methods of storing data will degrade over time. Anything less than engraving a message in stone, gold, or platinum and burying it will have some data loss eventually.

If the documents that need to be archived have no special requirements and if you have a good backup system in place (testing backup media, off-site storage in case of disaster, multiple sets of hardware that can read the backup media in case of hardware failure, etc) then you might be able to just store the documents on a server and include them in the backup plan. The regular backups should cater for replacing media over the long term. If however there is a significant amount of data or the data has confidentiality requirements that preclude having it all online all the time then you need a separate infrastructure for such storage.

Regular backup systems have to deal with files being deleted from storage and files that have their contents changed. For a document archiving system no file will ever be changed once it has been created and no file will be deleted. This allows some simplifications to the backup strategy. For example if you have multiple terabytes of documents backed up by tape and stored off-site you could use CD-ROMs or other media for storing recent changes. It would be very easy for an employee to grab a couple of CDs before rushing out of a burning building, but grabbing a set of tapes (or the correct tape from a large set) may not be possible.

It would be possible to use a tape library system as the primary storage for documents. If a large organization was going to implement this a few years ago that might be a good option. Nowadays storage is getting increasingly large and cheap. Terabytes are available in desktop PCs and hundreds of terabytes are available for server storage. So having the primary document store on a server with a decent amount of space and then making tape backups for storage in secure locations seems viable.

One thing to note about such document storage is that having everything on a server allows a much larger amount of data to be accessed and copied more easily than on paper. Sorting through a billion paper documents and copying the thousand most useful ones would be a difficult task for someone who was involved in industrial espionage. Finding the most useful files when they are indexed on a server should be quite easy and copying a few thousand is also easy (one thousand scanned documents of medium size should fit on a USB memory stick - much smaller than a few reams of copied documents).

Finally documents have to be archived in publicly documented file formats that can be easily read in the future. The PDF specification is well known and there are multiple programs that can display data in such files, another good option for scanned documents is JPEG. Proprietary formats such as MS-Word should never be used, you never know whether you will be able to read them in four years, let alone the seven years for which many documents must be retained or the 20-30 years that some documents must be retained.

Marc Brockschmidt wrote the BTS is too crowded and Joey Hess objected that a too clean BTS can also be a bad sign.

I think both is true or to say better none of the ways makes sense without the other:

Bug reports are in my eyes one of the most valueable resources we have. Noone can test everything even in almost trivial packages. To archive quality we need the users input and a badly worded bug report is still better than no bug report at all. Our BTS is a very successfull tool in that as it lowers the barrier to report issues. No hassles to create (and wait for completion of) an account, no regrets by getting funny unparseable mails about some developer changing their e-mail addresses (did I already say I hate bugzilla?).

As those reports are valueable information, one should keep them as long as they can be usefull. Looking at the description of the wontfix tag shows that even a request that cannot be or should not be fixed in the current context is considered valueable. Most programs and designs change, and having a place to document workarounds and keep in memory what open problems exist.

On the other hand a crowded bug list is like a fridge you only put food into. Over time it will start to degrade into the most displeasing form of a compost heap. The same holds for bug reports:

Most bugs are easier when they are young: You most propably have the same version as the submitter somewhere, know what changed recently and when you can reproduce it you get some hints on what is happening and get add it. If you cannot reproduce it, the submitter might still be reachable for more information.

When the report is old, things get harder. Is the bug still present? Was it fixed in between by some upstream release? Is the submitter still reachable and does still remember what happened?

When I care enough of a problem to write a bug report and trying to supply a patch for it, I try to always take a look at the bug list and look for some other low hanging fruits to pick and submit some other patch, too. (After all, most of the time is spend trying to understand the package and the strange build system upstream choose instead of plain old autotools and not when fix the problem). But when it is hard to see the trees because of all the dead wood around it, and there is nothing to find with some way to reproduce it and one knows far too well that the most efficient steps would be a tedious search for old versions to see if that was a bug solved upstream many years ago, good intentions tend to melt like ice thrown in lava.

So, when I wrote both is true I meant that keeping real-world issues documented and aware is a good thing. But having bugs rot (and often they do), will pervert all the advantages. In the worst case, people will even stop submitting new reports as it takes to long to look at all the old ones to look for a dublicate.

Since always I almost never have been able to organize properly my time. On top of that I tend to be
excited about various new things and keep on adding to my "sometime in the future" todo list. When I
decide is time to use the GTD technique, things start to improve. Sadly, I am not able to stick with
GTD 24/7.

Hello!

I decided is time to start blogging... so here is a first post.

Future topics: Debian, Romanian l10n, i18n and real life.

Blogging is hard, isn't it? Finding a topic that's not better placed on specific mailing list or somewhere else is not easy. One of the classical subjects for bloggers is ranting. And that's what I would love to do now :-)

I have had discussions with people who are turning away from Debian in the past few months, mostly to Debian derivatives like Ubuntu. Mostly, the reason for that is some sort of software that is newer/better supported/blabla in some other distribution, which I think is OK. Debian has a policy of a long, painful release cycle, but the stable releases that come out of it tend to be useful for a long time and relatively bug-free. That is good and shouldn't be changed without good reason.

Most of the people I spoke too revealed a far more disturbing thing: The long release cycle isn't the only argument against using Debian. Most of these people had other reasons, and a good number of those are things that Debian as a whole can - and should - address. Mostly, the Debian BTS comes up as a topic. Not because we don't use the Industry Standard [tm] bugzilla (which I personally hate so much I can't even describe), but because the BTS contains a lot of old bugs nobody cares about. Look at most of our packages: Bugs filed 7 years ago, with the last activity from that time, without a hint how (and if) they are ever closed are not uncommon; they are what you actually expect if you look at a bug list.

Naturally, processing, forwarding and closing bugs is the task of the maintainer. This doesn't work out in all cases, we have more than one cases where maintainers are overwhelmed by the sheer number of bugs flowing in against their packages. Also, and that is probably accepted everywhere: Bug processing is uncool. It is so much more fun to rewrite your code, add features, get new packages in the archive and doing new, blingy stuff, that the boring maintenance work of existing packages moves to a place far down on the todo lists. But hey, this maintenance. That's what maintainers are for. Most Debian Developers are Package Maintainers. They should do it, not adding new stuff.

We need to discuss how to work around these issues. We are not the only project which an overfilled bug tracking system. Look at the Gnome and KDE projects, the number of bugs filed against Mozilla products each day. Can we learn something from them? I would be happy to get a bit of feedback about this, so whoever is involved in other projects which have found better days to deal with bugs, please send a mail.

Apart from the fact that I would love to get more input on this, I want to start something new for lenny, the stable release planned after etch. I want to get the bug count down. Not the release critical bug count (which is eagerly watched all the time), but the small issues that bug users every day. For that, I have planned to look at 5 random important and normal bugs each day (starting with software I use) starting the day etch is released. I may begin to do this earlier, but I'm currently really not swimming in free time.

I don't plan on fixing all these issues (well, I may, if I can easily reproduce them), but more on forwarding them to the appropriate place, upstream, and noting so in the BTS. I want to poke maintainers long enough to invest some more time in fixing bugs. This will also help with the MIA efforts of the QA team, I guess...

Oh, what I almost forget: I expect help from all of you!