Difference between revisions of "Release Meeting Minutes/2009-06-23"
(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...)
|Line 1:||Line 1:|
'''Meeting notes for 2009-06-23:'''
'''Meeting notes for 2009-06-23:'''
Latest revision as of 23:57, 3 January 2011
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”.
- 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.