Release Meeting Minutes/2008-01-07
(New page: Minutes of weekly release meeting for 1/7/2008 3:30PM EST '''Public access to meeting minutes''' Wyl: meeting minutes to be public or not? Sam: want them to be that way eventually, exc...)
Revision as of 15:30, 15 January 2008
Minutes of weekly release meeting for 1/7/2008 3:30PM EST
Public access to meeting minutes
Wyl: meeting minutes to be public or not?
Sam: want them to be that way eventually, excluding confidential information
Wyl: important that changes in state between public and confidential information should be made clear to all during meetings.
Release status update
Sam: would like Sun to suggest people to do code review of krb trunk. MIT looking to help them define what to look for.
Kevin: CCAPI. Debugging client server interactions. Been communicating with lxs for help. Feels good about current state of project. Was able to reuse RPC code.
Tom: made progress on mechglue last week, additional work remains.
Sam: Tom should put fuller mechglue proposal onto k5wiki to get outside input.
Everyone's mostly up-to-date in Daptiv, MIT's project tracking system.
No one else brought up issues re: their release status
Wyllys: LDAP traversal / DAO layer issue
Tom: there for crash recovery (ex: berkeley db can cause data loss). It provides the possibility of salvaging more data in case of inconsistencies.
Wyl: DAO interface needs more backends
Sam: think that exists
Wyl: query mech?
Sam: very berkeley db specific. trying to preserve CLI.
Wyl: problems re incremental propagation. wants to query backend "do you support this?"
Sam: agrees that would be good, but not right for something this berkeley db specific. overkill
Wyl: Sun's incremental propagation isn't reasonable to use with an ldap backend
Sam: thought it was backend independent
Wyl: think there's an issue with locking. Will look into it.
Sam: But yes, query mech does seem reasonable.
Wyl: Might bring up on krbdev.
Sam: an example of why everyone needs to be involved in project reviews. involved at a point where everyone's concerns can be addressed
Wyl: or just define general principles on interface stability
Sam: Any interface stability principle will need a procedure for breaking an interface. There's always a question of what happens when two sets of code can't handle the same interface, requiring breaking. Agrees there should have been a better, more involved review.
Wyl: Or code review to catch that regression.
Sam: aware of changes, decided to accept them (not happy, but accepting the code was the best option, even with regressions/changes). If there was a better interface policy, would've been able to follow it. ABI and CLI stability are exactly what the Consortium needs to do.
Meeting end 3:56