I've still not consumed all your mail-text and will try to answer the easy parts.
* 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.
Telnet uses single DES (yes kenh, i know there is des3) and DES is broken.
This have been my argument all along, itsn't it better to give up and use a
better solution.
Removing telnet is not hard, I tried to convince users that its a good thing
to move away. If I was to use you as the "common" user, maybe removal
is the only way to make them understand.
Call me naive.
* 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.
There are weekly snapshots of the 0.7 branch being built, and those
contain all bugfixes that is easily migrated to 0.7 codebase.
The problem is not maintain braches, the problem is releases.
* 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.
Unbreaking heimdal for all platforms takes some time and last time
I got good help by David Love.
If you are interested in having Solaris maintained _during the development cycle_,
please contribute cycles to the making the build cluster larger.
* 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.
I don't understand how goals and targets gives more testers, please expand.
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?
You want an new person, the coordinator that is coordinating the few
people that tests Heimdal. What a waste. Have the person test Heimdal instead.