Re: The state of the heimdal project

[Harald Barth <haba@pdc.kth.se>]

Either I was not clear enough when I described the problem or you did
not understand what I wrote. Let me try to explain.

This is not about this or that patch or the speed with which patches
are addressed or solved. This is not about program development.
I have seen your work for several years and you get code written
with amazing speed and accuracy.

This is about project management or release management or whateve you
want to call it. This is about the dull and boring sides of this
line of work.

* Pruning dead branches of the code is such a boring side.

Example (this is telnet, this could be rsh etc etc):

> I don't agree, telnetd have always behavid this way, telnet is broken
> by protocol design and can hardly be fixed without protocol action by  
> ietf, are you willing to spend the time ?

If you don't like telnet choose one of the following:
   1. Support it nevertheless.
   2. Don't support it yourself, but take patches.
   3. Kill it.

The current situation with you disliking working with it, the code
hanging around in a kind of unsupported state and us who really use it
not being able to get the patches in _as_we_who_use_the_code_want_
_them_, is just frustrating. In that case, it is better to announce
"Telnet will be removed starting from release X". Then, we who use the
code will either cope and use something else or support it ourselves.

End example.

* Maintenance of non-current-releases is such a boring side.

Example:

I have not seen any statement about a 0.7.3 release date,
in spite of asking for it. My guess then, is that there
will be no 0.7.3 release.

End example.

If you don't plan to ship any maintainance release(s), say so.

* Support of a wide variation of platforms is such a boring side.

Example:

The 20060929 snapshot was not compiling on Solaris.

The current branch has been in existence since approx 20060302 and
somewhere between that date and now this broke. This can only happen
if there is no active development on Solaris.

End example.

Decide for release 0.8 if platform X is in or out.

* Testing functionality and keeping it continuing to work is such a
boring side.

Example:

Ticket forwarding broke at serveral places somewhere between 0.7 and
0.7.2.

This was not tested thoroughly enough.

End example.

You need more testers. You can only get more testers if there are
goals and targets. Getting testers is as hard as getting sponsors.
I'm trying to help with that, but I don't think I'm any good at it.

> If you commit testing resources I'll happily coordinate a release.

As the coordinator has to negotioate with the coder, you'll have to
negotiate with yourself and coordinate with the testers. Is that good?
I'm not a good coordinator. Can we find a good coordinator who not
necessarily is a coder?

> I got more questions when I'm going to release 0.8, so that is what
> I've been spending my time on.
>...
> 2005  - 205 days unique days that I commited code.

Let me repeat: I _am_ impressed. That does however not address the
problem that 99% of all users and admins can't safely use the package
if it requires the kind of treatment I needed to give it before it
started to work.

Harald.