Release Meeting Minutes/2009-06-23

Meeting notes for 2009-06-23:

1.8 Feature List Discussion

• Tentative feature plan found at http://k5wiki.kerberos.org/wiki/Release_1.8
• Do we have enough features planned for 1.8 for it to be compelling for users to take the new version?
• Tom sent the 1.8 proposal out on the mailing list, though it’s too early to have already gotten responses.
• Discussed possible approaches for enabling administrators to specify enctypes.
  • Admin could modify defaults list or
  • We provide syntax for enabling/disabling enctypes based on functionality
  • For example, admin could say “I want all but SHA1” and it would go through and remove all enctypes that use SHA1.
  • Syntax would be limited. For instance we would not support complex conditions as in "Give me all enctypes that support ('this' AND 'this') OR 'this'".
• Discussed improving the database abstraction layer
  • Database layer is currently too “blobby” – in order to change a field, you must read in all data, modify the desired field, and write the data back to the db.
  • Also due to blobs, logging only records that changes were made to a blob and does not indicate which specific field changed.
  • We want to add finer grain access to the db, such that specific fields can be changed without reading/writing entire blobs of data.
  • Discussed the possibility of adding a new API & backend while supporting the old API as this would allow code to be migrated incrementally. However, it was suggested that this might ultimately result in a poor API design; change to a new API should be all-or-nothing.
  • Discussed the possibility of improving the API to support finer grain control using the exiting db. However, this could hurt performance.
  • Will indicated that db improvements had been discussed previously at Sun. He will find the mail thread and forward it on for review.
  • Consensus was that rewriting the db layer would take too much time for the 1.8 release, though design work will be ongoing.
• Tom discussed calling out items on the roadmap that have deliverables with specific deadlines/milestones (such as coming up with a design for the new db layer) that are not associated with a specific release.
• Discussed reducing DNS dependence.
  • Still need to formulate a good plan to reduce DNS dependence.
  • Currently a global switch turns off all reverse DNS.
  • Allowing individual clients to disable DNS for specific realms could be a usability problem.
  • A possible solution would be to add additional information to the KDC, allowing it to specify capability to the client. Possibly as a new ticket flag in the TGT.
• Discussed localization support for error messages.
  • Whether or not the Consortium provides localized messages, it would be nice to have a framework or support for providing localization.
  • Will is going to write up a proposal based on past work with Solaris.
  • Based on proposal we will decide whether this ends up in 1.8.

Coding Styles and Transition Strategies

• When and how should we perform the “grand reindent”?
  • We should do it as soon as possible instead of in stages.
• What editor mode lines should be supported/included in formatted code files?
  • For now, include only Emacs mode lines.
• What formatting rules should be strictly enforced?
  • We should enforce tab rules and trailing whitespace.
• Discussed methods of enforcing style rules.
  • We could include a script that would run on SVN commit and check for formatting violations.
  • Files that have been reformatted and should therefore continue to comply with formatting would have a flag (using an Emacs mode line).
  • SVN would reject commits for files with the flag that do not comply.
  • If we must make a non-conforming change, then we could check in a change that turns off the flag. Then commit the violating code.
  • The script would most likely check the flag status of the file version already in the repository, so if the flag is accidentally deleted on a commit, the file would still be checked for style compliance.
  • We should also include a style-checking script that developers could run before trying to check in any code. Should be part of the standard development procedures to avoid sloppy code.
  • We could possibly add the script to “make check”.

Proposal Policies

• Proposals will be made on the wiki.
• Discussions should be on the mailing list since not everyone has proper watches set on the wiki.
• We will link to the pipermail archive of the discussion thread from the wiki.