logo_kerberos.gif

Difference between revisions of "Release Meeting Minutes/2008-02-04"

From K5Wiki
Jump to: navigation, search
(minor correction to my comments)
(Append Steve's directive that Kevin review user manual.)
Line 92: Line 92:
   
 
Ken: Printed it but not read it. About 40 pages. There are similar how-to guides out there but this may be one of the larger ones I've seen.
 
Ken: Printed it but not read it. About 40 pages. There are similar how-to guides out there but this may be one of the larger ones I've seen.
  +
  +
Steve: Kevin should look at it.

Revision as of 22:33, 4 February 2008

Minutes of weekly release meeting for 2008-02-04:

Will: Out sick last week.

Tom: Who is up to date in Daptiv?

Alexis: Up to date

Ken: Behind, needs to fix timescales

Kevin: Up to date

Ken: Working on a lot of stuff unrelated to 1.7

Tom: Should we add non-1.7 projects to make it easier to see who is doing what?

Ken, Steve: Yes

Tom: Trying to reproduce database corruption bug. Partial progress.

Will: Shawn Emery and Tom in communication about database corruption?

Tom: Yes

Will: Shawn had something that reproduces this?

Tom: We have one test case which reproduces some of the corruption we've seen. Describes test case with a record split on index 0.

Ken: Can we replace with a different database? SQLite plugin?

Will: Sun looking into SQLite already.

Ken: Believes SQLite license is sufficiently public domain for our purposes. Apple also using SQLite. Has heard concerns about SQLite being slower than Berkeley DB.

Will: Would there be any problem with a plugin in MIT Kerberos for SQLite?

Tom: Plugin isn't a problem for MIT. Vendors might have an issue if we bundle SQLite with MIT Kerberos. Would make sources considerably larger (1MB of sources).

Ken: Could choose to not build it on platforms where SQLite libraries already exist.

Will: Sun uses SQLite in some components. Also just bought MySQL. Thinks Nico uses SQLite. Sun is interested in a more reliable and robust database backend than LDAP or Berkeley DB.

Tom: Berkeley DB is well-tested and very mature. Unfortunately 4.4 BSD had the last incarnation of Berkeley DB under a license we could use so we are using an old version. MIT Kerberos will compile against more recent Berkeley DB versions.

Ken: Tested Berkeley DB versions 3 and 4.

Tom: No idea if anyone is using Kerberos with more recent versions of Berkeley DB. However given the interest in SQLite we should bring it up to the board and try to find resources.

Will: My manager may want me to switch to working on SQLite plugin instead of the enctype migration work.

Steve: How is our work going? Been working with Sun since October officially but seems like we aren't really getting to collaborate as much as we'd like.

Will: Feel like I haven't gotten a chance to really work on the Consortium work due to hardware issues, holidays, illness, LDAP bugs, release requirements, etc. Everything else was high priority.

Steve: That's understandable. Just want to flag that we've got a commitment from Sun for 6 months of 2 people at 25% time. Don't want to get into a state where we save all the work until the end and then don't have reasonable projects or deadlines. Even if this particular project isn't working we could use QA, testing infrastructure, new services (eg: OpenGrok), etc.

Will: Need to talk to manager about this.

Will: What is the project tracking system you are using?

Steve: Daptiv PPM. Is MIT's project tracking system. Have getting Sun folks accounts as an action item. Should be easy if you have an MIT account.

Will: Yes I have an MIT account. Do all board members get access to this?

Steve: Any board members can get access to this, but I suspect most don't want that fine grained detail. However since you're working so closely with us it should be useful to you.

Tom: Any other updates, issues, interesting developments?

Alexis: CCAPI v2 needed for Windows. Working on it. Will delay other tasks by approximately a week.

Kevin: Coverity Update. Have access to web site and downloaded their tool. Currently scanning krb5 sources and all other open source projects is done by one guy. Trying to move to a model where the open source projects run the tools themselves, upload dump files to an ftp site and he will run the proprietary tools on them and post results. Not currently automated, but working on that. Analysis takes approximately twice as long as a build.

Tom: What are the tool requirements? OS?

Kevin: Coverity wants to start with Linux first. Need to be able to protect access to the tool.

Ken: Can we talk about results of the tool output? Can we publish our results?

Steve: We should look at the license.

Tom: Do we have licenses?

Kevin: Haven't signed anything yet or received any formal notices. Will look for READMEs in tool tarball.

Steve: Would it be easier to use commercial project?

Kevin: Commercial product is expensive. Will investigate licensing of commercial product. Would get both pieces of the tool and not have to deal with Coverity.

Ken: Will help Kevin with linux build.

Steve: Has anyone looked at the user manual posted to comp.protocols.kerberos?

Ken: Printed it but not read it. About 40 pages. There are similar how-to guides out there but this may be one of the larger ones I've seen.

Steve: Kevin should look at it.