- Wednesday, November 18, 2015

release-team@conference.openafs.org

Wednesday, November 18, 2015< ^ >

Room Configuration

Room Occupants

GMT+0
[07:17:55] kadukoafs@gmail.com/barnowl650AA74C leaves the room
[07:18:06] kadukoafs@gmail.com/barnowl650AA74C joins the room
[13:24:56] kadukoafs@gmail.com/barnowl650AA74C leaves the room
[13:25:04] kadukoafs@gmail.com/barnowl650AA74C joins the room
[13:39:23] shadow@gmail.com/barnowlABEE2063 leaves the room
[13:39:33] shadow@gmail.com/barnowlABEE2063 joins the room
[13:59:18] meffie joins the room
[14:20:08] mvita joins the room
[14:59:05] wiesand joins the room
[15:01:13] <wiesand> Hello
[15:01:41] <wiesand> Anybody out there?
[15:01:58] <mvita> I'm here
[15:02:02] <mvita> sorry.
[15:02:09] <mvita> was reviewing stuff ;-)
[15:02:19] <Jeffrey Altman> hello
[15:02:35] <wiesand> Hi Mark. Do go on ;-)
[15:02:35] <mvita> Hello Stephan and Jeffrey!
[15:02:36] <Jeffrey Altman> this week is Super Computing '15 in Austin TX.
[15:03:03] <wiesand> Yes, two of my colleagues are there.
[15:03:14] <wiesand> But it’s not about AFS, is it?
[15:03:18] <Jeffrey Altman> ask them to stop by booth 271
[15:03:39] <wiesand> Will do. Is it the YFS/Auristor booth?
[15:03:46] <Jeffrey Altman> They can say hello to the AuriStor team
[15:04:33] <wiesand> Is Marc there too?
[15:04:56] <Jeffrey Altman> Marc is experiencing the first snows of the season
[15:05:18] <wiesand> So, no, I reckon.
[15:05:30] <Jeffrey Altman> He is not in Austin
[15:05:44] <wiesand> Anyway, does anyone have news regarding Linux 4.4?
[15:05:52] <Jeffrey Altman> changes will be required
[15:06:02] <wiesand> Great :-/
[15:06:17] <Jeffrey Altman> its still to early in the cycle to know how disruptive they will be in total.
[15:06:39] <wiesand> Thanks.
[15:07:24] <wiesand> I’d like to issue 1.6.16pre1 a.s.a.p. and release 1.6.16 shortly before Xmas.
[15:07:46] <Jeffrey Altman> sounds reasonable
[15:07:54] <wiesand> Linux 4.4. could then be dealt with in 1.6.16.1 .
[15:08:04] kadukoafs@gmail.com/barnowl650AA74C leaves the room
[15:08:06] <Jeffrey Altman> also reasonable
[15:08:06] kadukoafs@gmail.com/barnowl650AA74C leaves the room
[15:08:06] kadukoafs@gmail.com/barnowl650AA74C leaves the room
[15:08:06] kadukoafs@gmail.com/barnowl650AA74C leaves the room
[15:08:06] kadukoafs@gmail.com/barnowl650AA74C leaves the room
[15:08:32] kadukoafs@gmail.com/barnowl9D2BE25B joins the room
[15:09:32] <kadukoafs@gmail.com/barnowl9D2BE25B> Sounds reasonable, yeah.
[15:10:38] <wiesand> I think we’re basically ready for pre1. Some trivial doc stuff may still go in, but probably not much more.
[15:11:13] <wiesand> The only real obstacle from my point of view is a reasonable paragraph on 11594 for the release notes.
[15:13:01] <wiesand> Or maybe that doesn’t belong into the release notes at all?
[15:13:06] <kadukoafs@gmail.com/barnowl9D2BE25B> "Prevent spurious call aborts due to erroneous idle timeouts"
[15:13:28] <wiesand> Thanks :)
[15:13:54] <mvita> yeah, that will work.
[15:15:34] <wiesand> That ncurses thing would be nice (12098).
[15:16:10] <wiesand> But shouldn’t delay the prerelease.
[15:18:22] <kadukoafs@gmail.com/barnowl9D2BE25B> Oh, Christof posted an update already, hooray.
[15:18:55] <wiesand> Regarding 12085:
[15:19:34] <wiesand> I think Mark’s complaints are valid. But to me it looks like those problems are present on master too?
[15:19:50] <mvita> yes
[15:20:25] <wiesand> So let’s leave it as is for the time being, as a reminder that it should be fixed on master and pulled up then.
[15:20:55] <wiesand> What about 12097?
[15:21:18] <kadukoafs@gmail.com/barnowl9D2BE25B> Regarding 12098, the autoconf manual says "If no includes are
specified, the default includes are used ", but I don't know that
explicitly passing [] qualifies as "no includes are specified".
[15:22:50] <wiesand> merged 12096
[15:24:16] <meffie> > What about 12097?
bosserver is the only thing at this time that calls afsconf_SetExtendedCellInfo, i could add the error message there?
[15:25:01] <meffie> (instead of a printf?)
[15:25:14] <wiesand> btw, where will that printf  actually go?
[15:25:41] <mvita> I was wondering about that myself
[15:25:52] <mvita> was waiting for meffie to make his changes first
[15:27:33] <meffie> well, it should be logged i would think.
[15:27:55] <meffie> so the error would be returned to the caller.
[15:28:06] <wiesand> what’s so ugly about it then?
[15:29:12] <kadukoafs@gmail.com/barnowl9D2BE25B> Library code should generally try to avoid having side effects, like
writing to the terminal.
[15:29:20] <meffie> well, it would be a bozo_Log call not a printf
[15:29:44] <mvita> ah
[15:30:17] <meffie> yes, what ben just said. thank you. :)
[15:31:38] <Jeffrey Altman> afsconf_SetExtendedCellInfo() like afsconf_SetCellInfo() before it is a public exported function that is permitted to be used by out of tree applications.   You cannot change the signature.  You must add a new function.
[15:32:37] <meffie> yes, i dont think we wanted to change the signature.
[15:33:04] <kadukoafs@gmail.com/barnowl9D2BE25B> I thought it would just be returning an error value and having the
caller interpret that value.
[15:35:11] <meffie> we could put the printf back, or add a function to pass a logging callback function.
[15:35:43] <kadukoafs@gmail.com/barnowl9D2BE25B> I find it really hard to get excited about logging callback functions.
[15:35:52] <mvita> how so?
[15:35:55] <kadukoafs@gmail.com/barnowl9D2BE25B> I'm inclined to just put the printf back for now.
[15:36:10] <meffie> sounds good enough for me.
[15:36:41] <wiesand> I’m just a bit reluctant to merge 12083 without something to reinstate the message...
[15:36:51] <meffie> > how so?
it's more plumbing.
[15:37:03] <wiesand> If you think that’s overly pedantic please tell me
[15:37:07] <mvita> I ask because this reminded me of 10717 where I add a logging callback for otherwise lost rx msgs
[15:37:43] <kadukoafs@gmail.com/barnowl9D2BE25B> That is probably overly pedantic, but I do not object to your proposed
course of action.
[15:39:36] <kadukoafs@gmail.com/barnowl9D2BE25B> mvita: and I'm not super-excited about 10717, either.  But it might be
the least-bad thing to do (I didn't think about it very hard when I
last looked at it).
[15:41:00] <Jeffrey Altman> network protocol stacks should not have logging functions.
[15:41:06] <mvita> sure - but if logging callbacks are considered an anti-pattern, I will abandon it.
[15:41:27] <Jeffrey Altman> network stacks are performance critical
[15:41:38] <wiesand> Looks like we’ll go with 12097 for the time being, and with that pulled up 12083 is good to go.
[15:42:00] <meffie> excellent! thank you wiesand.
[15:43:06] <wiesand> 12100 is so trivial I’d merge it even without review...
[15:43:29] <mvita> for 12085 would you like me to push a fix to master for later pullup?
[15:43:59] <wiesand> If we think this is worth doing?
[15:44:08] <wiesand> 12085 is just skew reduction.
[15:44:20] <kadukoafs@gmail.com/barnowl9D2BE25B> merged 12097
[15:44:23] <meffie> $ ls /usr/afs/logs/Sal*
/usr/afs/logs/SalsrvLog  /usr/afs/logs/SalsrvLog.old
[15:44:41] <wiesand> The fixes for master are actually more important.
[15:44:58] <wiesand> Ben: Thanks.
[15:47:21] <kadukoafs@gmail.com/barnowl9D2BE25B> Mark: please push a fix to master for the issues raised in 12085
review.
[15:47:37] <mvita> will do
[15:49:17] <wiesand> pullup of 12097 is 12105
[15:49:25] <wiesand> Mark: great
[15:50:12] <wiesand> merged 12100
[15:50:50] <wiesand> what else "must" make 1.6.16?
[15:51:40] <wiesand> The prdb stuff is a bit complex and required some fiddling (+12101). Can it wait?
[15:52:22] <mvita> 11654 afs: shake harder in shake-loose-vcaches
11702 volser: range check acl header fields during dumps and restores
11703 volser: detect eof in dump stream while reading acl
[15:52:36] <meffie> well, i'd like to see 11654
[15:53:08] <meffie> perhaps, i could split that into 2 commits.
[15:53:08] <kadukoafs@gmail.com/barnowl9D2BE25B> 12101 looks like it's supposed to be just code cleanup with no behavior
changes, which therefore could wait.
[15:53:09] <wiesand> None of those were merged on master yet.
[15:53:33] <meffie> yes
[15:53:43] <mvita> 11742 prdb_check: fix out of bounds array access in continuation entries
11751 prdb_check: check for continuation entries in owner chains
[15:53:55] <wiesand> Yes it can. But it’s the bottom of the prdb stack for a reason ;-)
[15:54:14] <kadukoafs@gmail.com/barnowl9D2BE25B> BTW I have a video call at the hour and expect to not be able to pay
attention after that.
[15:55:51] <wiesand> I’m afraid waiting for stuff not yet landed on master will make it impossible to release 1.6.16 this year.
[15:56:17] <wiesand> The same probably for sufficient review of the prdb stack.
[15:56:20] <kadukoafs@gmail.com/barnowl9D2BE25B> That seems like the correct approach to take, Stephan.
[15:56:30] <meffie> ok
[15:56:48] <meffie> prdb_check is not critical
[15:57:12] <meffie> (obviously)
[15:57:14] <mvita> it is if your prdb doesn't check
[15:57:56] <meffie> heh, you can use an old version to check.
[15:58:32] <mvita> oh, so older versions are not susceptible - okay
[15:58:51] <wiesand> ?
[15:58:59] <kadukoafs@gmail.com/barnowl9D2BE25B> Er, I thought that that prdb_check stack is not regression fixes.
[15:59:05] <meffie> well, versions already built on old versions of gcc.
[15:59:14] <kadukoafs@gmail.com/barnowl9D2BE25B> That the code has always been "broken", but older compilers let it
slide.
[15:59:18] <meffie> yes
[15:59:38] <mvita> ewww.
[16:01:52] <meffie> anyone using prdb_check on rhel7 will be sad.
[16:02:17] <mvita> I think we should include that.
[16:02:21] <kadukoafs@gmail.com/barnowl9D2BE25B> Before I disappear, just wanted to toss out a couple 1.8 tidbits:
in 11729, are we happy with stderr vs. the stdout used by other
salvage components?
In 12074, should we just finish up 11852 and expect that to resolve
the build failures?
[16:03:37] <meffie> will look
[16:03:37] <mvita> 11729:  no strong feelings either way
[16:07:13] <wiesand> You mean prdb_check on EL6 is safe, but on EL7 it will ruin your prdb?
[16:08:05] <meffie> well, prdb_check crashes on rhel7
[16:08:45] <meffie> i dont think it will ruin your db file, but i cant say it will not.
[16:08:55] <mvita> re: 12074 & 11852 - pursue both independently, I think
[16:09:02] Daria joins the room
[16:09:30] <mvita> the former is tactical, the latter is strategic
[16:09:30] <meffie> (and i say rhel7 because that has a newer gcc)
[16:10:44] <meffie> it's kind of an interesting bug. c undefined behavior.
[16:12:19] <wiesand> Ok. But rhel7 or newer compilers have been around for a while. And the changes touch ptserver code, so should be reviewed thoroughly. I just don’t see that happening this week.
[16:12:37] <wiesand> And then 1.6.16 would slip past the holiday season.
[16:12:49] <meffie> oh, those *are* on master now.
[16:12:52] <meffie> 15e8678 prdb_check: fix out of bounds array access in continuation entries
3e9e244 prdb_check: check for continuation entries in owner chains
[16:12:53] <wiesand> And we’ll have linux stuff in the way again.
[16:13:20] <meffie> i'll submit the 1.6.x versions right now.
[16:13:24] <wiesand> Well I made an attempt to pull them up today.
[16:13:28] <wiesand> 12101..4
[16:14:36] <wiesand> http://gerrit.openafs.org/#q,status:open+project:openafs+branch:openafs-stable-1_6_x+topic:prdb,n,z
[16:14:38] <kadukoafs@gmail.com/barnowl9D2BE25B> > are on master now
Yup, I snuck in some surprises last night.
[16:15:04] <wiesand> NB thanks for that
[16:16:50] <meffie> woot! thanks Ben
[16:17:41] <wiesand> merged 12083 and 12105
[16:18:13] <meffie> oh, and thanks wiesand. i see your pullups.
[16:20:36] <wiesand> So, candidates left are 12089 and prdb. Otherwise there’s just another NEWS update left to do before pre1 can go out.
[16:21:38] <meffie> i'll review / test the prdb pullups.
[16:22:49] <meffie> thank you.
[16:25:11] <wiesand> I’m not going to finish it up tonight... so, what gets sufficient review today (Eastern time) can still go in. If I have to fight fires, maybe Friday. But I wouldn’t want to wait longer before issuing and announcing pre1.
[16:25:24] <meffie> btw weisand, the prdb_check changes do not change the ptserver code
[16:26:02] <kadukoafs@gmail.com/barnowl9D2BE25B> The structure of what code gets built for which tools is pretty
convoluted in src/ptserver, yeah :)
[16:26:39] <wiesand> display.c display.h
[16:27:04] <wiesand> 12101 also changes ptserver.h ptutils.c utils.c
[16:27:20] <wiesand> without that, more skew :-(
[16:27:40] <meffie> print_entry is only use by prdb_check and the ptclient test program
[16:28:04] <wiesand> So, zero risk?
[16:28:59] <meffie> i could rebase the changes without the extra PR_REMEMER_TIMES changes.
[16:29:15] <kadukoafs@gmail.com/barnowl9D2BE25B> I reviewed PR_REMEMBER_TIMES just now; it's fine.
[16:29:51] <meffie> ok, then yes, this does not change the prdb server code. just the prdb_check and ptclient test program.
[16:30:24] <meffie> (if it did, i would split it into separate patch sets)
[16:30:32] <wiesand> I really prefer reducing the skew w.r.t. master where feasible, rather than piling it up.
[16:31:10] <meffie> ok, understood.
[16:31:29] <wiesand> Since I have the feeling that 1.6 will live on for a while ;-)
[16:31:50] <mvita> 1.4 certainly did
[16:33:01] <wiesand> Ok. Anything else to discuss today?
[16:33:15] <kadukoafs@gmail.com/barnowl9D2BE25B> Well, while I have meffie<more>
[16:33:15] <meffie> no thank you
[16:33:22] <meffie> oh?
[16:33:50] <mvita> heh\
[16:34:03] <kadukoafs@gmail.com/barnowl9D2BE25B> For 11816, do you think we can get away with pusing a one-off change
instead of rebasing the whole stack?
I sort of expect that gerrit will get unhappy for the subsequent man
page changes, though.
[16:35:43] <meffie> yes, would think one-off change is fine. i can do that.
[16:35:55] <kadukoafs@gmail.com/barnowl9D2BE25B> Thanks.
[16:37:06] <meffie> do you think the externalize-log-rotate stack is close?
[16:37:47] <wiesand> 1.6.16 shall not be delayed for including that ;-)
[16:37:49] <kadukoafs@gmail.com/barnowl9D2BE25B> Well, I only got partway through last night.
Much of the early cleanup I would have just merged if it wasn't
dependent on 11816.
[16:37:59] <kadukoafs@gmail.com/barnowl9D2BE25B> wiesand: ;-)
[16:38:22] <kadukoafs@gmail.com/barnowl9D2BE25B> There may still be issues with the more contentful parts of the stack;
I don't really remember how they were when I left them.
[16:38:39] <meffie> ok
[16:40:27] <meffie> ok, have a good day all.
[16:40:41] <kadukoafs@gmail.com/barnowl9D2BE25B> You, too
[16:40:56] <wiesand> Thanks for a very productive meeting!
[16:40:59] <wiesand> Bye.
[16:41:53] wiesand leaves the room
[16:45:48] <mvita> bye
[16:51:07] meffie leaves the room
[20:28:26] kadukoafs@gmail.com/barnowl9D2BE25B leaves the room
[20:28:34] kadukoafs@gmail.com/barnowl9D2BE25B joins the room
[20:47:37] shadow@gmail.com/barnowlABEE2063 joins the room
[20:48:33] shadow@gmail.com/barnowlABEE2063 leaves the room