logo_kerberos.gif

Release Meeting Minutes/2009-06-23

From K5Wiki
< Release Meeting Minutes
Revision as of 09:16, 24 June 2009 by Rsilk (talk | contribs) (New page: '''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...)

(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search

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.