I looked at a number of trouble ticket and bug tracking systems in the last two days. To put it mildly: they all lack.
I'm astonished that the majority of them, especially the newer ones, are web-based. Hey, people, get a clue:

• discussions with clients is best done through email.
• email has lower turnaround times.
• if done correctly email is more secure, especially if you don't use passwords. [use a one-time key for each trouble ticket, and let the customer decide with whom he wants to share this]. This obviously isn't that important in for open source bug tracking.

Well, maybe it's just me, but i don't want to use a web browser to update the state of a ticket after i resolved the thing together with the customer. I just want to set the state to resolved in the last mail i send.
Apart from that email is just more easy - to use and to program processors for.

And all i've seen seem to be a bit unflexible. I'm not going to introduce different task-systems for company hotline (non-software customers), software customer support and developers internal stuff. My cow-orkers would kill me before i finish the sentence, i think.
In other words: the basic design has to be very, very simple, but extensible.

There is nothing wrong with having a web interface (aside from the simple fact that i will not use it if i don't need to use it), but being forced to use one? Heck, no.
And you can't easiely put something else about a web interface, but you can create some kind of web interface for almost everything without too much work.

I also went through my personal todo list:

1. BBS software: decided to not work on it anymore. Not even bug fixing. It's not something i want to continue working on. I wouldn't design it like this, and the basic design is from 1988 or so (and the UI is even older). Period.
2. gateway: will rewrite it. The basic design is still ok, but i' m a better coder today, and have learned a few lessons. Beside that: I now have some libraries with i didn't have in 1993, and they _will_ make the thing more beautiful. But the change is quite fundamental, and anyway, the best way to get rid of bloat and historical workaround in code is to rewrite it.
   Schedule: don't know.
3. utftpd: i'll rewrite it. The configuration file language is fine, except there shouldn't be a configuration file language at all. Yeah, it's highly flexible. And this is not needed.
   I'll keep the one client, one TFTP server process design for now, but will cleanup the server if i happen to find something which wouldn't work in a single server design. I'm still unsure whether multicast TFTP is useful. Mind you, utftpd has been written to backup my router configuration files.
   Schedule: This year.
4. udpserver: decided to finish it. I need something like this to start the TFTP server.
   Schedule: Soon.
5. syslog server: decided to finsish it. I do not really need it, (except that linux sysklogd is horrible), but a clean and reliable implementation of a syslog daemon which doesn't fill the disk is worthwhile. [takes and translates network input, sends it to multilog]
   Schedule: Soon. What needs to be done is to write a useful configuration tool.
   Originally i didn't ever want to use it one any other machine then the log server at my workplace, but now i think this software might be useful for others, too.
   • speaking of linux sysklogd: That hack _still_ loses if the syslogd is restarted. I sent a fix for that to the authors / maintainers in 1996 and 1998. See this patch. Shall i be amused?
6. lrzsz v1: i'm tempted to remove all traced of internationaliation from lrzsz. gettext _still_ is at version 0.10.35, and still throws out that annoying warning that messages must not contain \r (which is wrong, btw). I would also get rid of a number of bugs in Makefile.in.in, of which the wrong usage or not-usage of DESTDIR is the most annoying. And building the package on a machine without GNU make will then be possible.
   No, i'm not volunteering to maintain gettext.
   Schedule: Still undecided.
   • in case you wonder: my personal build environment disencourages warnings. It's quite annoying to get them mailed twice a day.

7. lrzsz v2: Will possibly finish writing X/Ymodem sender and receiver tools this year. I'm not happy about the sender state machine now, it works, but it looks ugly. This needs more thinking.
   The Zmodem state machine will get even more ugly. I need to re-read a few descriptions of the protocol first.
8. watchdog: the watchdog software the company uses now could benefit from a cleanup. It now runs for more than 6 months, and all the problems with the design should have shown up by now. Actually quite a number did show up, and the ad-hoc changes not only made the code messy, but desynchronized code and documentation.
   Schedule: This year.
   Mostly easy stuff, but the scheduler ... at the moment the interval of 300 seconds is fixed. I should get rid of this, for cleanness sake. Oh, and i need to convince the boss to release it under GPL. Should be easy.
9. conflib:
   support discontinued. I don't use it anymore.
10. ftpcopy:
    i will implement some kind of "move" functionality -

           ftpcopy ftp://re.mo.te/ ./re.mo.te/
    
           (cd re.mo.te ; find . -type f -print0) | xargs -0
    
    
               ftpdelete ftp://re.mo.te/ 
    

    Not using -print0 is also possible. Files with \n inside the file name are then just not deleted. (i suspect that the are impossible to download anyway).

Netscape eats an astonishing amount of memory now. Oh, well. Maybe i should start to post with some other tool.