[OpenAFS-devel] release-team meeting minutes 2015-03-18

[Benjamin Kaduk]

On Wed, 18 Mar 2015, Stephan Wiesand wrote:

> Log: http://conference.openafs.org/release-team@conference.openafs.org/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