Is anyone or a group of people able to maintain appl/bsd better than MIT

[Darren Reed (Optimation)]

From: "Sam Hartman" <hartmans at mit.edu>
> So, it seems that at least one of our assumptions may be wrong and
> several people have stepped forward and indicated they would continue
> needing rcmd-based applications even if we drop them.

Yes, if not telnet and ftp as well.

[...]
> MIT has significant experience with producing useful technology, but
> not doing a good enough packaging job that others feel the need to
> take over the packaging.  All this experience is bad: we tended to get
> multiple versions, incompatibility, API/feature set divergence, and
> failure to fix bugs in all versions.

I don't quite get how packaging fits in here unless you mean it isn't
straight forward to build an RPM out of the Kerberos .tar.gz source
code.  (for example)

> It seems that if we do decide to drop appl/bsd, we should treat it
> like the other applications and find something to recommend in its
> place that is compatible.

This is a serious problem.  I view the set of programs inside of
appl/bsd as being guaranteed to work with MIT Kerberos.  If
you go out to 3rd parties for these tools then you lose some
level of assurance that it will "just work".

> Currently MIT is providing critical bug fixing services for these
> applications and is doing fairly little else to them.
> 
> Are there any individuals or groups of people out there who believe
> they could do a better job and would be willing to try?

In all honesty, how much work needs to be done on them?
Is the protocol used by rlogin/rsh/rcp going to change in the
next 12 months in such a substantial way that they are going
to need to be written 5 times ?  (exageration)

In comparison to ftp and telnet, which do seem to be evolving
still, the others appear to be fairly static but it sounds like you
are short on "monkeys" to turn the wheels...

You are already using CVS for development of MIT Kerberos,
I hope, and rather than split these out of the "official" Kerberos
distribution, maybe the team of responsible parties needs to expand
with some extra parties taking on "official" responsibilities for
subsections of the Kerberos tree.  Is this sort of thing attractive
to the core group of people working on MIT Kerberos ?  I would
put up my hand to help here if this was workable (heck, I would
help out if appl/bsd were separated but I'd *really* like us to
find a solution that doesn't require that.)

I'd really much prefer to not have to bring in 3rd party telnet/ftp
and BSD r* programs to build a Kerberos package for customers.
If they want more advanced versions of those tools (such as those
found in SRP telnet or whatever) then we can deal with that then.
There is no way we would consider ssh a "drop in" replacement
for the BSD r* programs under any circumstances.

Darren