- Wednesday, January 6, 2016

release-team@conference.openafs.org

Wednesday, January 6, 2016< ^ >

Room Configuration

Room Occupants

GMT+0
[07:59:56] shadow@gmail.com/barnowlABEE2063 leaves the room
[08:00:08] shadow@gmail.com/barnowlABEE2063 joins the room
[08:02:01] kadukoafs@gmail.com/barnowl7482D0F3 leaves the room
[08:02:30] kadukoafs@gmail.com/barnowl7482D0F3 joins the room
[08:10:06] kadukoafs@gmail.com/barnowl7482D0F3 leaves the room
[08:10:17] kadukoafs@gmail.com/barnowl7482D0F3 joins the room
[08:11:19] shadow@gmail.com/barnowlABEE2063 leaves the room
[08:11:33] shadow@gmail.com/barnowlABEE2063 joins the room
[08:25:17] kadukoafs@gmail.com/barnowl7482D0F3 leaves the room
[08:25:26] kadukoafs@gmail.com/barnowl7482D0F3 joins the room
[14:42:13] Jeffrey Altman leaves the room
[14:50:28] meffie joins the room
[14:52:06] Jeffrey Altman joins the room
[14:52:11] kadukoafs@gmail.com/barnowl7482D0F3 leaves the room
[14:54:19] kadukoafs@gmail.com/barnowlFBAB7144 joins the room
[14:58:08] wiesand joins the room
[15:02:55] <wiesand> Hello
[15:03:20] Daria joins the room
[15:03:26] <Daria> hi
[15:04:13] <wiesand> Linux 4.4 news, anyone?
[15:05:19] <kadukoafs@gmail.com/barnowlFBAB7144> Greetings
[15:05:58] <wiesand> Looks like we have to face the fact that the times where we were ready for new mainline kernels at the time of their release is over :-(
[15:07:34] <wiesand> So, no point in waiting with merging changes to make a 1.6.16.1 painless.
[15:07:45] <kadukoafs@gmail.com/barnowlFBAB7144> Has anyone asked Marc directly?
[15:08:16] <wiesand> No. I’m a bit reluctant to do it...
[15:12:51] <kadukoafs@gmail.com/barnowlFBAB7144> I will add it to my todo list, I guess.
[15:13:40] <wiesand> You may well know better whether it’s still appropriate.
[15:15:11] <wiesand> Anything major coming up for 1.6.17 then?
[15:16:01] <kadukoafs@gmail.com/barnowlFBAB7144> I should probably actually add the config files for FreeBSD 10.2 like
I threatened to do ages ago.
[15:16:34] <wiesand> That would even fit a 1.6.16.1.
[15:16:40] <kadukoafs@gmail.com/barnowlFBAB7144> FreeBSD 11-current has been broken for a while, though; I made some
progress over the holidays, but a bit more analysis is needed.
[15:17:31] <wiesand> There are also some fbsd10-checking pullups that were lingering for a while.
[15:18:04] <wiesand> Looks like we should mostly clear the backlog for the next release.
[15:19:19] <kadukoafs@gmail.com/barnowlFBAB7144> Sure.
[15:19:30] <wiesand> Anything regarding 1.8 then?
[15:19:43] <meffie> i dont have anything new for 1.6.17
[15:20:46] <kadukoafs@gmail.com/barnowlFBAB7144> I guess I could say a few things.
[15:21:01] <wiesand> go ahead
[15:21:57] <kadukoafs@gmail.com/barnowlFBAB7144> Mike has been pushing updates to the external-log-rotation bits to
address review comments, which is good.  There's still a couple
questions left about how to handle the various logging options and
global variables, but we probably don't need to talk about those here.
[15:22:34] <meffie> ok, feel free to contact me offline.
[15:22:57] <kadukoafs@gmail.com/barnowlFBAB7144> Chas is doing a hefty chunk of review, which also helps.
I don't think anyone has commented on the rxgen cleanup to support
64-bit size_t in struct rx_opaque
[15:23:21] <kadukoafs@gmail.com/barnowlFBAB7144> (The rxgen-size-t-workaround topic, ah.)
[15:23:51] <kadukoafs@gmail.com/barnowlFBAB7144> So, if we have some time today, I'd like to try to take a pass through
the -1-reviewed changes and see if we have any actual release blockers
in there.
[15:24:07] <kadukoafs@gmail.com/barnowlFBAB7144> Since those would be good things to try to get volunteers to work on
:)
[15:24:18] <kadukoafs@gmail.com/barnowlFBAB7144> I think the appropriate gerrit search query would be:
label:Code-Review=-1 Verified=1 status:open NOT label:Code-Review=-2
branch:master NOT message:windows NOT label:Code-Review=2
project:openafs
[15:25:12] <kadukoafs@gmail.com/barnowlFBAB7144> akeyconvert and the externalize-log-rotation bits I think we've
already talked about as being blockers.
[15:27:31] <kadukoafs@gmail.com/barnowlFBAB7144> I'm not sure I'm getting the correct summary for what the 'hardmount1'
topic is supposed to do just by skimming the changes in it, but it
doesn't really look like a release blocker at the moment.
[15:28:25] <meffie> i think it is really a bug fix; so should not be a blocker
[15:28:35] <kadukoafs@gmail.com/barnowlFBAB7144> Okay.
[15:28:50] <kadukoafs@gmail.com/barnowlFBAB7144> Next up: 11851 "Change null variable checks to make clang
tautological-pointer-compare happy."
[15:29:09] <kadukoafs@gmail.com/barnowlFBAB7144> I think we should address the underlying issue for the release, but I
think there is a different option that I prefer.
[15:29:34] <meffie> ok
[15:29:35] <kadukoafs@gmail.com/barnowlFBAB7144> Namely, 11852+11853
[15:30:54] <kadukoafs@gmail.com/barnowlFBAB7144> 11853 has a +1 from meffie, but 11852 doesn't seem to have any
reviews.
[15:31:38] <kadukoafs@gmail.com/barnowlFBAB7144> (Did everyone find the gerrit settings knob that lets you have the
change number show up in the search results?)
[15:32:33] <meffie> Maximum page size?
[15:33:00] <kadukoafs@gmail.com/barnowlFBAB7144> There's a different one, but that one's good, too.
[15:33:04] mvita joins the room
[15:33:20] <mvita> sorry, got tied up elsewhere
[15:33:31] <kadukoafs@gmail.com/barnowlFBAB7144> "show change number in changes table"
[15:34:54] <wiesand> now if we could sort by change number...
[15:35:16] <wiesand> but yes, I had found that knob and turned it on
[15:35:22] <meffie> show the change number is very nice. i'm glad they brought that back!
[15:36:09] <kadukoafs@gmail.com/barnowlFBAB7144> Stephan, any thoughts about 11765 "
RedHat: Make overriding the CellServDB to package actually work"?
[15:36:35] <wiesand> "not a blocker" ;-)
[15:36:46] <kadukoafs@gmail.com/barnowlFBAB7144> Works for me ;)
[15:37:08] <wiesand> There’s probably a better fix which works in more cases.
[15:37:16] <kadukoafs@gmail.com/barnowlFBAB7144> 11902 "afs: build option to enable vcache lru checks"
[15:38:08] <kadukoafs@gmail.com/barnowlFBAB7144> Probably also not a blocker, I guess.
[15:38:17] <meffie> agree on 11765 (i dont need that option at this time)
[15:38:45] <wiesand> I should abandon 11300. The solution is LSB compliant packaging, not this hack.
[15:39:26] <meffie> yes, use modern paths on ro /usr
[15:40:13] <kadukoafs@gmail.com/barnowlFBAB7144> 11908 "afs: renumber vlru inconsistent panic messages"
[15:40:24] <wiesand> byebye 11300
[15:40:37] <meffie> 11908 is not urgent
[15:41:37] <meffie> it was something noticed while working on a different fix.
[15:41:55] <kadukoafs@gmail.com/barnowlFBAB7144> *nods*
[15:42:01] <mvita> aren't they all?
[15:42:06] <meffie> (that happens so often, i need a code word for such)
[15:42:17] <kadukoafs@gmail.com/barnowlFBAB7144> 11871 "ubasics/bucoord/butc: make tape sizes unsigned" feels like
not-a-blocker
[15:42:25] <meffie> "rubbernecking?"
[15:42:48] <kadukoafs@gmail.com/barnowlFBAB7144> (s/ubasics/bubasics/)
[15:43:09] <kadukoafs@gmail.com/barnowlFBAB7144> 11697, "libafs: Add new syscall for cache initialization"
Hmm, what did I have to say about this...
[15:43:30] <kadukoafs@gmail.com/barnowlFBAB7144> Oh, I said "I do not see this feature as a blocker for 1.8", okay
then.
[15:44:09] <meffie> might be good to have on a release boundary.
[15:44:34] <mvita> aye
[15:45:33] <meffie> i can take a look (after the log stuff i hope)
[15:45:35] <kadukoafs@gmail.com/barnowlFBAB7144> Maybe, but I think I stand by my "I do not plan to re-review it
unless a new revision gets some +1s."
[15:45:41] <meffie> yes
[15:46:03] <kadukoafs@gmail.com/barnowlFBAB7144> Andrew has a dcache-32bit-overflow topic.
[15:48:08] <kadukoafs@gmail.com/barnowlFBAB7144> It seems like the core change is only relevant when talking to a
server that is broken in "interesting" ways, but could also be
considered a bugfix.
Given that Andrew is not super-active at the moment, this seems like
"not a blocker".
[15:48:55] <mvita> EWOULDBLOCK
[15:49:14] <mvita> agreed, should not be a blocker
[15:49:52] <kadukoafs@gmail.com/barnowlFBAB7144> 1975, "vos partinfo: enable tabular output"
(the number is not a typo).
Not really a blocker, but could easily make it with just a little bit
of attention, I think.
[15:50:56] <meffie> would be a nice feature for sure.
[15:51:30] <kadukoafs@gmail.com/barnowlFBAB7144> Hmm, what did I say on Marcio's listvldb-cache topic...
[15:52:01] <meffie> he was using something out of opr for hash, iirc
[15:53:08] <kadukoafs@gmail.com/barnowlFBAB7144> pthread mutex initialization, opr_queue and dict, mutex assertions,
pull out switch from gethostbyaddr to getnameinfo into a separate
commit
[15:53:40] <kadukoafs@gmail.com/barnowlFBAB7144> So, a fair bit of reworking.
[15:54:06] <wiesand> If you give me 11903, I’ll abandon 11766 and promise to work on the other redhat ones in the list...
[15:54:12] <kadukoafs@gmail.com/barnowlFBAB7144> I don't think I can advocate for that being a blocker.
[15:54:28] <mvita> for the listvldb cache, agreed
[15:54:50] <mvita> however, the side issue of switching from gethostbyaddr to getnameinfo would be nice to do on a release boundary
[15:54:51] <meffie> it would be very nice to have though :)
[15:55:12] <mvita> and not just here, but other places where we are using "old" resolver calls
[15:56:11] <kadukoafs@gmail.com/barnowlFBAB7144> Maybe the release boundary where we bring in ipv6 support? ;)
[15:56:17] <meffie> !
[15:56:33] <mvita> snarky!
[15:56:47] <mvita> but well played
[15:57:39] <kadukoafs@gmail.com/barnowlFBAB7144> Hmm.  I might consider a feature-freeze exemption for that, but I
don't remember enough of the differences in the APIs to justify why it
would be good.
[15:57:48] <kadukoafs@gmail.com/barnowlFBAB7144> Also, I turn into a pumpkin in a couple minutes.
[15:58:54] <mvita> we've got one or two tickets here that are artifacts of DNS infrastructure (e.g nscd) not playing well with AFS use of those deprecated resolver calls
[15:59:55] <mvita> especially in the client -afsdb code
[16:00:07] <kadukoafs@gmail.com/barnowlFBAB7144> > client afsdb one
12118?
[16:00:24] <meffie> let's not conflate, i'll talk to marcio about vos-listvlb-cache topic
[16:00:32] <kadukoafs@gmail.com/barnowlFBAB7144> Okay.
[16:00:55] <kadukoafs@gmail.com/barnowlFBAB7144> (not 12118)
[16:01:22] <kadukoafs@gmail.com/barnowlFBAB7144> (12118 is the thing where you get 127.0.53.53 as the address for TLD
cells in dynroot)
[16:01:31] <mvita> not 12118, correct
[16:02:49] <wiesand> Thanks for 11903
[16:03:07] <wiesand> Are we finished for today
[16:03:09] <wiesand> ?
[16:03:37] <kadukoafs@gmail.com/barnowlFBAB7144> Well, y'all could keep going without me, but maybe.
[16:03:55] <meffie> oh, 11903, nice!
[16:03:59] <mvita> OT:  stephan, the backport I promised you is coded and almost done testing
[16:04:22] <wiesand> Great, thanks a lot!
[16:04:56] <mvita> gotta go for now, sorry
[16:05:16] <wiesand> Let’s call it a meeting then. I have to run too.
[16:05:20] <wiesand> Thanks a lot everyone!
[16:05:24] <meffie> thanks. bye.
[16:05:34] meffie leaves the room
[16:05:39] mvita leaves the room
[16:06:29] wiesand leaves the room
[16:25:39] mvita joins the room
[16:25:49] mvita leaves the room
[19:57:43] meffie joins the room
[20:50:30] meffie leaves the room