[1779] in Kerberos_V5_Development
V1.0 release
daemon@ATHENA.MIT.EDU (Sam Hartman)
Sun Sep 22 15:52:11 1996
Date: Sun, 22 Sep 1996 15:52:05 -0400
From: Sam Hartman <hartmans@MIT.EDU>
To: krbcore@MIT.EDU
Cc: jis@MIT.EDU
About two weeks ago, Jeff was in the SIPB office and casually
mentioned that V1.0 of Kerberos V5 needed to come out around November.
Beta7 had not even been released yet, so this was a very short time
However, he had some fairly convincing reasons why the release
politically had to happen.
I don't know if we do plan on making a release in this time
frame, but no one I've talked to on the Kerberos team--including
Tom--was aware of a impending release. So, if we actually are going
to make a November release, Ted needs to decide it's going to happen
now, and we need to get organized.
In particular, to release before the end of the year, we
should develop a fairly finalized todo list before the end of
September, and develop a time table for the release. An end of
September deadline for a todo list is agressive (There is just over a
week left), but necessary for a successful release.
Developing the todo list now is important so that all members
of the Kerberos team know what issues are important enough to make it
into the release, and which of the many potential features and
improvements tentatively discussed for V1.0 should be put aside. For
example, Ted mentioned that getting multiple encryption types working
was still a high priority in the Beta7 README. However, this task
alone could easily take the free time of several people between now
and November. Other areas that may be potentially time consuming
include deciding how to handle application configuration (Should
krb5.conf enable encryption?), redesigning the build system or using
Dejagnu for all testing. These and many other improvements or
suggested changes probably ought to wait until after V1.0 comes out.
Before our next release, I think we should also come up with
a formal release guideline/procedure. In the two releases I have
witnessed so far, a lack of a well-thought-out procedure has lead to
last minute changes that have introduced glaring, obvious bugs into
the release just before it shipped. Problems like the failure of
login to forward tickets, the inability of Beta7 to configure
correctly, Beta6 not passing shs tests, and Beta5 leaking memory don't
have to happen.
In closing, we have a very strong group of people currently
working on the project, and there's no good reason we can't produce
quality work that sets an example in the security community. However,
to do this, we need a clear goal in mind as well as a clear
understanding of what we are doing and how we should do it.
--Sam
