Difference between revisions of "Release Meeting Minutes/2008-06-16"
(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...) |
(No difference)
|
Revision as of 10:36, 7 July 2008
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