https://k5wiki.kerberos.org/wiki?title=Release_Meeting_Minutes/2009-06-23&feed=atom&action=historyRelease Meeting Minutes/2009-06-23 - Revision history2024-03-28T08:52:54ZRevision history for this page on the wikiMediaWiki 1.27.4https://k5wiki.kerberos.org/wiki?title=Release_Meeting_Minutes/2009-06-23&diff=3732&oldid=prevTomYu at 03:57, 4 January 20112011-01-04T03:57:12Z<p></p>
<table class="diff diff-contentalign-left" data-mw="interface">
<col class='diff-marker' />
<col class='diff-content' />
<col class='diff-marker' />
<col class='diff-content' />
<tr style='vertical-align: top;' lang='en'>
<td colspan='2' style="background-color: white; color:black; text-align: center;">← Older revision</td>
<td colspan='2' style="background-color: white; color:black; text-align: center;">Revision as of 03:57, 4 January 2011</td>
</tr><tr>
<td colspan="2" class="diff-lineno">Line 1:</td>
<td colspan="2" class="diff-lineno">Line 1:</td>
</tr>
<tr>
<td colspan="2" class="diff-empty"> </td>
<td class="diff-marker">+</td>
<td style="color:black; font-size: 88%; border-style: solid; border-width: 1px 1px 1px 4px; border-radius: 0.33em; border-color: #a3d3ff; vertical-align: top; white-space: pre-wrap;"><div>{{minutes|2009}}</div></td>
</tr>
<tr>
<td class="diff-marker"> </td>
<td style="background-color: #f9f9f9; color: #333333; font-size: 88%; border-style: solid; border-width: 1px 1px 1px 4px; border-radius: 0.33em; border-color: #e6e6e6; vertical-align: top; white-space: pre-wrap;"><div>'''Meeting notes for 2009-06-23:'''</div></td>
<td class="diff-marker"> </td>
<td style="background-color: #f9f9f9; color: #333333; font-size: 88%; border-style: solid; border-width: 1px 1px 1px 4px; border-radius: 0.33em; border-color: #e6e6e6; vertical-align: top; white-space: pre-wrap;"><div>'''Meeting notes for 2009-06-23:'''</div></td>
</tr>
<tr>
<td class="diff-marker"> </td>
<td style="background-color: #f9f9f9; color: #333333; font-size: 88%; border-style: solid; border-width: 1px 1px 1px 4px; border-radius: 0.33em; border-color: #e6e6e6; vertical-align: top; white-space: pre-wrap;"></td>
<td class="diff-marker"> </td>
<td style="background-color: #f9f9f9; color: #333333; font-size: 88%; border-style: solid; border-width: 1px 1px 1px 4px; border-radius: 0.33em; border-color: #e6e6e6; vertical-align: top; white-space: pre-wrap;"></td>
</tr>
</table>TomYuhttps://k5wiki.kerberos.org/wiki?title=Release_Meeting_Minutes/2009-06-23&diff=1284&oldid=prevRsilk: 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<p>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...</p>
<p><b>New page</b></p><div>'''Meeting notes for 2009-06-23:'''<br />
<br />
1.8 Feature List Discussion<br />
<br />
* Tentative feature plan found at http://k5wiki.kerberos.org/wiki/Release_1.8<br />
* Do we have enough features planned for 1.8 for it to be compelling for users to take the new version?<br />
* Tom sent the 1.8 proposal out on the mailing list, though it’s too early to have already gotten responses.<br />
* Discussed possible approaches for enabling administrators to specify enctypes.<br />
** Admin could modify defaults list or<br />
** We provide syntax for enabling/disabling enctypes based on functionality<br />
** For example, admin could say “I want all but SHA1” and it would go through and remove all enctypes that use SHA1. <br />
** 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'".<br />
* Discussed improving the database abstraction layer<br />
** 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. <br />
** Also due to blobs, logging only records that changes were made to a blob and does not indicate which specific field changed.<br />
** We want to add finer grain access to the db, such that specific fields can be changed without reading/writing entire blobs of data.<br />
** 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.<br />
** Discussed the possibility of improving the API to support finer grain control using the exiting db. However, this could hurt performance.<br />
** Will indicated that db improvements had been discussed previously at Sun. He will find the mail thread and forward it on for review.<br />
** Consensus was that rewriting the db layer would take too much time for the 1.8 release, though design work will be ongoing. <br />
* 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.<br />
* Discussed reducing DNS dependence.<br />
** Still need to formulate a good plan to reduce DNS dependence.<br />
** Currently a global switch turns off all reverse DNS.<br />
** Allowing individual clients to disable DNS for specific realms could be a usability problem. <br />
** 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.<br />
* Discussed localization support for error messages.<br />
** Whether or not the Consortium provides localized messages, it would be nice to have a framework or support for providing localization.<br />
** Will is going to write up a proposal based on past work with Solaris.<br />
** Based on proposal we will decide whether this ends up in 1.8.<br />
<br />
Coding Styles and Transition Strategies<br />
<br />
* When and how should we perform the “grand reindent”?<br />
** We should do it as soon as possible instead of in stages.<br />
* What editor mode lines should be supported/included in formatted code files?<br />
** For now, include only Emacs mode lines. <br />
* What formatting rules should be strictly enforced?<br />
** We should enforce tab rules and trailing whitespace.<br />
* Discussed methods of enforcing style rules.<br />
** We could include a script that would run on SVN commit and check for formatting violations.<br />
** Files that have been reformatted and should therefore continue to comply with formatting would have a flag (using an Emacs mode line).<br />
** SVN would reject commits for files with the flag that do not comply.<br />
** 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.<br />
** 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.<br />
** 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. <br />
** We could possibly add the script to “make check”. <br />
<br />
Proposal Policies<br />
<br />
* Proposals will be made on the wiki.<br />
* Discussions should be on the mailing list since not everyone has proper watches set on the wiki. <br />
* We will link to the pipermail archive of the discussion thread from the wiki.</div>Rsilk