Release Meeting Minutes/2008-10-07

Meeting notes for 2008-10-07:

Master key rollover project:

• Will will respond to Ken's comments and make some additions to the test plan on the project page.
• The project has been approved.

Wiki:

• Tom has added a "Lore" category with some notes.
• Target audience: development contributor
• Visibility in order of expanding levels of engagement:
  • I want to report a bug
  • I want to submit a patch
  • I want to write better patches
    • Coding standards
    • Building from source
    • Running the test suite
  • I'm interested in the active projects
  • I'd like to know about inactive project ideas and designs
  • I'd like to know how one becomes a committer
  • I am a committer or staff member
    • How to use the repository
    • How to use the Coverity infrastructure
    • How to use the test lab infastructure
• Greg will take responsibility for improving the wiki, but not immediately
• The wiki should not be used for discussion (that's what the list is for), but should be used to summarize the results of discussions so they don't get lost in the list archives. This will require human effort; there is no automated process for converting good discussions into good summaries.

Testing:

• One of our test cases references an MIT DNS record; we can use "host" to determine whether to run that test case
• Test suite should ideally be self-contained with regard to the net
• In the long run, we could produce better unit tests if the test suite could divert the network layer and return pre-coded results (including errors). Greg may implement this eventually.
• Unit tests of that nature are inherently limited and are not a substitute for full integration tests
• One of the Berkeley DB hash tests is failing for Will; we can't reproduce it currently. He will look into it.

Road map for KDB:

• Separate DB lookup functionality into functional components, such as "the information needed to grant a ticket"
• Current model is tailored to BDB and a particular data model
• With functional APIs, the data model coudl be made more friendly to a relational database or LDAP database
• Start by creating APIs implemented on current data model
• Later, migrate to more natural data models
• Old APIs might need to be preserved, but would become less efficient when used with new data models.