logo_kerberos.gif

Release Meeting Minutes/2008-06-16

From K5Wiki
< Release Meeting Minutes
Revision as of 10:36, 7 July 2008 by Jander (talk | contribs) (New page: Present: Justin, Ken, Robert, Tom, Will '''Status''' Justin: krb5_cc_* locking on schedule Will: Close, dump MT conversion - niggly details remain. Hopefully done by end of week. regard...)

(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search

Present: Justin, Ken, Robert, Tom, Will

Status

Justin: krb5_cc_* locking on schedule

Will: Close, dump MT conversion - niggly details remain. Hopefully done by end of week. regarding master key rollover, need to look at schedule and update estimate.

Ken: Debugging iprop now. kdb5util create sets up log, kadminlocal propagates, kpropd crashes

Robert: mysql working, though in a rough state. kerberized server and client for windows

Tom:

  • requirements gathering for dev priorities
  • next - longterm roadmap for dev timelines
  • client support for princ referrals needs to work better
    • public functions changed behavior when princ referrals were implemented -- was a major change for afs krb folk
    • ken: ran into that with iprop, failed to parse with ipc issues
  • two projects touching db code, would be wise to pick which to merge ahead of time (iprop, keytab migration)
    • ken, will: don't expect there to be much overlap. even if there is, it won't be difficult to fix
  • doxygen-ified version of krb5.h will appear shortly for peer review.
    • generated docs will also be available, probably as zipped html.
    • due to time limits, mostly dictated by budget constraints, review period will be about a week.
    • over 250 macros and functions

API

tom: any thoughts to new api design?

will: looked into improving dao interface

tom: db abstraction would make many proposed projects easier to implement. Also, 250 functions is a little to large for an API

ken: if we aim for something more object-oriented, 250 isn't a hard number to hit

tom: gss api also unwieldy in its own way, with functions which take a dozen params

will: would be good to break down API redesign into manageable chunks

tom: whatever we do, it would be good to align with Heimdall. want to avoid portability problems