Where 1.5 work is going on: integration road map

[Sam Hartman]

Hi folks.  I wanted to write a brief note describing what is going on
with the 1.5 release and where you can find bits of it.  We seem to be
using Subversion in different ways than CVS and that may make the
development process less obvious to outsiders familiar with how we
were doing things.

The trunk needs to stay in a relatively release-ready state from this
point on out.  It's actually not as release-ready as we'd like it to
be, but that needs to get better not worse.

So, that means that we're doing a lot more work on branches than we
used to do.


The trunk has a database plugin architecture.  There is only one
database backend.  There's currently a significant problem in that
existing config files may not work correctly with this backend; that
is a release blockre.


There are several active branches with ongoing development:

branches/ldap-integ: This includes an LDAP backend as well as some
updates to the error handling to actually report useful errors
including names of distinguished names and attributes from the
backend.  Unfortunately we're going to have to rework parts of the
error handling.  Currently error information is stored in thread local
storage.  We'd rather include error information in the krb5 context in
a manner similar to how Heimdal handles things.  That means changing
all the calls that will touch error handling.  There are also a number
of build issues that need to be addressed before this code can make
its way onto the trunk.

External parties are looking at this branch.  So, it needs to be
synchronized closely with the trunk.  IT definitely should not fall
more than a week behind the trunk.  It also needs to build and it
needs to work better over time; there should not be significant
regressions on this branch.

Changes to the database layer should generally be made here not to the
trunk unless such changes fix a critical problem for the 1.5 release.
Any changes made to the database layer on the trunk should typically
prompt a merge of the trunk to this branch.


users/raeburn/branches/plugins: Ken is working on a generic plugin
framework.  He's also been working on a plugin interface for adding
behavior to the service location system.  This could be used for
example by AD integrators to choose the best DC for the site in
question.  This framework will be used on all platforms to build and
find plugins for the KDC location plugin, for database plugins and for
GSS-API mechanism plugins.

users/tlyu/branches/mechglue: Tom is working on integration of GSSAPI
mechglue patches from Sun as well as a SPNEGO mechanism.  Currently we
are building a library that includes the mechanisms hard-coded.  


Integration steps.

Most things are gating on Ken's plugins work.  That needs to stabelize
a bit and get into a state where the plugins framework is being used
for DAL plugins.  That will presumably still be on his private branch.

Then, Tom's GSS-API code needs to be merged onto a branche containing
Ken's plugins code (probably ending both of the ancestor branches to
avoid too many parallel branches).  Then Tom's GSS work needs to start
using the plugins.

At some point, the plugins work needs to meet the LDAP work.  This can
happen either if the plugins merges onto the trunk (and then
ldap-integ is synchronized with the trunk) or if the plugins (possibly
combined at this point with GSS) merges onto the ldap-integ branch and
the whole mess eventually hits the trunk.