Release Meeting Minutes/2008-09-09
Meeting Notes 2008-9-9
Attendees: Will, Tom, Alexis, Ken, Zhanna, Justin
Tom: Project proposal?
Will: Got some comments from Love and others.
Tom: Key rollover to application servers? Adding support for issuing new keys to application server for the service principal.
Will: Didn't make it into design. Can go back and try to add that functionality. Updating service keys.
Tom: Want to have an inactive service key to distribute and then activate it at some point.
Will: Run kadmin on a server and ktadd. Generates new keys on the KDC and keytab. What's the scenario in this case?
Tom: If you have a service using a single service principal on multiple hosts. Want to create a new key and mark it as inactive. Distribute it to all the servers and once all the servers have it, mark it as active. AFS and some other Kerberized servers use the same key for all servers. Not the best way of using service keys but is needed in some circumstances.
Will: Similar to master key rollover.
Tom: Want to use mechanism for master key rollover for application service keys.
Will: Send a review comment. Not going to have time to implement it, but would like to accomodate it.
Tom: Updates. Will do you have anything extra?
Will: Received Tom and Ken's comment on checklist. Will update and send out revised version. Next step: post on wiki as example?
Tom: Yup.
Will: Some other points that have come up would be more appropriate in process documentation.
Justin: Working on KIM UI.
Zhanna: Finishing up rcache project. Gearing up for new project.
Ken: ASN.1 code
Alexis: KIM library stuff. Cleaning up error handling and threads support.
Tom: Apple loose ends. Client side principal referrals code. walk_rtree code.
Tom: Would like to make this more of a development meeting. Not just about next release but also also big goals. Short term goals: KIM, iprop, master key rollover, etc. Mid to long term goals should be architectural goals. Behind on keeping architecture and design clean. What do people think are the code problems? What get in the way the most?
Code problems (from team):
- Lack of consistent C style (indenting, tab width, etc)
- Not enough comments
- Code duplication
- Redundant macros and definitions
- Too many warnings
- Cross-platform test suite
- Nightly builds and tests
Will: Sun has been looking at what it would take to make the MIT source base as a drop-in. Can pass along report to MIT when work is completed. (eg: Debug logging, Internationalization support, kernel support, etc)
Tom: For fixing we were thinking of fixing indentation all at once.
Alexis: Indentation inconsistency gives people a bad first impression. So while it's probably a very minor thing it has a big impact in developer happiness. Doing it all at once means that developers have a clear idea of what code should look like just by looking at the code.
