23 Sep 2000 (updated 24 Sep 2000 at 08:32 UTC)
»
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:
- 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.
- 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.
- 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.
- udpserver: decided to finish it. I need something
like this to start the TFTP server.
Schedule: Soon.
- 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?
- 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.
- 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.
- 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.
- conflib:
support discontinued. I don't use it anymore.
- 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.