TomYu at 03:57, 4 January 2011

2011-01-04T03:57:12Z

Rsilk: 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...

2009-06-24T13:16:54Z

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...

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 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.

← Older revision		Revision as of 03:57, 4 January 2011
Line 1:		Line 1:
		+	{{minutes\|2009}}
	'''Meeting notes for 2009-06-23:'''		'''Meeting notes for 2009-06-23:'''

Release Meeting Minutes/2009-06-23 - Revision history

TomYu at 03:57, 4 January 2011

Rsilk: 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...