Difference between revisions of "Release Meeting Minutes/2008-08-26"

Revision as of 12:55, 26 August 2008

Release Meeting Notes 8/26/2008

Tom: Status updates: Been working on Kerberos Lite (client only libraries). RT server upgrade waiting on hostname rename scheduling. Integrating patches. Hiring.

Zhanna: Working on replay cache performance analysis. Found a couple places for performance improvements.

Will: Spent some work with Nico to improve replay cache code. In OpenSolaris. Might want to look at that replay cache code to see if there is anything of use.

Ken: Authorization data plugin patch integration. Working on more patches this week.

Justin: Stellar.

Alexis: KfM 6.5a4. Warning removal patches. Hopefully will have a chance to work on KIM. Out of town Thursday and Friday.

Will: Published (?). Brain dump of keytab stash project. Recommendations for RT ticket states.

Tom: Is project proposal process to time consuming?

Will: Good to have an initial proposal phase which doesn't require design, test plan, etc.

Tom: So a stage where you propose ideas without having to flesh them out?

Will: Yes. Just need enough detail to evaluate proposal. More explicit documentation on steps would also be good. Like the brain dump I sent.

Tom: Flow chart?

Will: Whatever makes sense. Could do something where people step through a process so they only see the current step and aren't overwhelmed with documentation. Also need more tool documentation. Lots of tools (RT, svn, etc) which people may not be familiar with.

Tom: We can come up with explicit instructions for things like merging.

Will: Best practices would also be useful. Things like creating a build directory outside the working directory, how to run a regression test (system requirements, steps, etc), when to run a regression test, etc.

Tom: Ken and I can work from your draft and put something up on the wiki.

Will: Can discuss in email.

Tom: Need to distinguish policy and procedure pages so they are easy to find.

Will: Would love to see something up to date, concise and well organized.

Tom: Do you think our current wiki needs reorganization?

Will: I think so. Hard to navigate when approaching it from the first time.

Tom: Any other issues?

Steve: If we push back the deadline for krb5 1.7, will that give you enough time to do the master key rollover?

Will: Need to look at my schedule. I will send you an estimate.

Steve: Fantastic.

Will: What is the policy on patch releases?

Tom: No official policy. Usually in response to security vulnerability or specific features people need in older releases.

Will: Wondering if master key rollover could make it in a patch release to krb5 1.7 if it didn't make the first release.

Steve: iProp and master key rollover are complimentary because iprop is a reason to upgrade and master key rollover makes upgrading much easier. We get to choose the date we release so we can delay for it if we don't have to delay too long.

Tom: What release are you running?

Will: It's a mix of different releases. We have taken lots of features without taking whole releases. Resyncs are very time consuming and risky. Would like to get to a point where Sun is taking whole releases.

Tom: Where is the most divergence? How can we help?

Will: Crypto layer has been modified to use Solaris crypto layer. Internationalization support. Split up code because some Kerberos code is in a kernel module which talks to a GSS daemon running in user space. Some code organizational support to get both user space libraries and kernel code building.

Tom: Would a more modular Kerberos be helpful?

Will: Would have to look at the code. Need to figure out what would be required of the consortium and come up with a proposal. More efficient if Sun does the research first.

Tom: Does Sun use MIT's RPCSEC implementation?

Will: As far as I know we use the Sun one.

Tom: Would like an acceptably licensed copy of Sun's RPCSEC.

Will: CDDL?

Tom: I believe some of our other vendors can't use CDDL.

Will: Would like the Kerberos consortium to take our code without licensing issues. May be necessary to get a drop-in code base and remove much of the Sun specific patches. Need to figure out what the licensing issues are. Need to get lawyers involved.

Tom: Did get license settled with iprop donation but that was probably separate.

Will: So MIT would like the Solaris implementation of RPCSEC?

Tom: Yes, would like a modern RPC implementation.

Steve: Need to write up as a proposal.

Will: Hopefully with specifics we can work it out. Beneficial to Sun if MIT takes Sun's RPC.