Difference between revisions of "Release Meeting Minutes/2008-01-07"

Latest revision as of 16:36, 10 January 2011

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