On Wed, 18 Mar 2015, Stephan Wiesand wrote: > Log: > http://conference.openafs.org/[email protected]/2015-03-18.html > > == 1.8 release == > > Readiness of the master branch for 1.8.0pre1 is blocking on code review > too. Ben will send a list of changes in gerrit to review next if you'd > like to help 1.8 along.
Review on 9985 would be helpful, since that's a big change to move AFSDIR_PATH_MAX-size buffers off of the stack (and we increased the value of AFSDIR_PATH_MAX recently, so stack-smashing would be a real concern). vos release -stayonline seems too risky to keep in 1.8, so review on 11787 is needed. Likewise, there is skepticism on "lockless path through afs_linux_dentry_revalidate", and thus review on 11793 is welcome. The rest of that topic may or may not make it into 1.8, but this change is not very coupled to the other ones. We seemed to have agreement on the vos changeaddr client-side check for mh entries implemented in 11638, but that doesn't have enough review to get merged yet. There are some jenkins hash conversions and hash table size increases in 11673 and 11679 that Hans-Werner tested; those should be pretty quick reads (and the former is marked +2 by me anyway). Mike's 'externalize-log-rotation' topic needs review. I wrote a utility to help with moving keys from rxkad.keytab to KeyFileExt as part of the upgrade; that's in 11786 (with some dependencies preceding it). Bikeshedding^Wsuggestions on the name of the tool are welcome :) I also did some documentation updates relating to the KeyFileExt, in 11769 and 11770. There's a 'linux24' topic to start to deorbit that code, since we seem to have consensus to desupport such systems, but that doesn't really need much review given what it is, and Perry has gone through them already. Deorbiting linux24 would pave the way for 6947 to go in, but that hasn't been rebased yet, so it's not quite ready for review. I've been using 11349 as a placeholder for "encryption by default", but I do not expect it to go in as-is -- more development work is needed before code review is helpful. It would be nice to have 7896 go in, but it's probably not a strict blocker. Likewise for 10789 -- more discussion may be needed, and it's not a strict blocker. Any contributions would be quite welcome. Thanks, Ben _______________________________________________ OpenAFS-devel mailing list [email protected] https://lists.openafs.org/mailman/listinfo/openafs-devel
