- Wednesday, March 30, 2016

release-team@conference.openafs.org

Wednesday, March 30, 2016< ^ >

Room Configuration

Room Occupants

GMT+0
[13:12:36] meffie joins the room
[13:21:45] kaduk joins the room
[13:26:01] kadukoafs@gmail.com/barnowl15A61B68 joins the room
[13:26:23] <kadukoafs@gmail.com/barnowl15A61B68> [verifying that I can talk to release-team from here as well as
openafs]
[13:26:30] <Jeffrey Altman> yes
[13:26:50] <Jeffrey Altman> here I kaduk and four kadukoafs
[13:26:59] <kaduk> "But I still get four copies in my kadukoafs barnowl"
[13:27:31] kadukoafs@gmail.com/barnowl15A61B68 leaves the room
[13:27:40] <Jeffrey Altman> boo
[13:27:40] kadukoafs@gmail.com/barnowlD2481C74 leaves the room
[13:27:40] kadukoafs@gmail.com/barnowl2F6B45A5 leaves the room
[13:27:40] kadukoafs@gmail.com/barnowl8F57DFC6 leaves the room
[13:27:40] kadukoafs@gmail.com/barnowl2F6B45A5 leaves the room
[13:27:51] <Jeffrey Altman> and now all of the kadukoafs are gone
[13:27:57] kadukoafs@gmail.com/barnowl15A61B68 joins the room
[13:28:06] <Jeffrey Altman> and one has returned
[13:28:28] <kadukoafs@gmail.com/barnowl15A61B68> Yeah, it seems that someone sending a message to the room while I'm
not actually in the room is enough to boot the ghosts.
[13:28:53] kaduk leaves the room
[13:57:24] wiesand joins the room
[14:03:18] <wiesand> Hello
[14:04:17] <wiesand> o...o...o...o...
[14:04:24] <mvita> hi!
[14:04:52] <kadukoafs@gmail.com/barnowl15A61B68> greetings
[14:04:59] <meffie> hello
[14:05:39] <wiesand> Thanks for being here.
[14:05:45] <wiesand> Linux news, anyone?
[14:06:27] <wiesand> I’ll take the silence as a no.
[14:06:30] <mvita> no news.  I looked briefly at what would be required for 4.5
[14:06:48] <wiesand> Good. But no results yet?
[14:06:49] <mvita> but haven't set up a 4.5 machine yet.
[14:07:07] <mvita> sorry, typing is quite slow for me.
[14:07:20] <wiesand> what’s wrong?
[14:07:42] <mvita> nothing's wrong, I just work better by voice.
[14:08:15] <wiesand> this isn’t exactly natural for me either ;-)
[14:08:21] <mvita> yeah.
[14:08:57] <mvita> I thought I had some 4.5 notes, but I can't find them atm
[14:09:01] <mvita> so sorry, no details.
[14:09:15] <wiesand> Thanks anyway. So, next topic. 1.6.18 (unless the next security release gets in the way)
[14:09:35] <wiesand> I rebased and merged a few changes today.
[14:09:43] <wiesand> Among them, the 4.4 stuff.
[14:09:43] <kadukoafs@gmail.com/barnowl15A61B68> yay
[14:09:46] <mvita> I saw, thanks!
[14:09:59] <meffie> thank you.
[14:10:05] <wiesand> Sorry for my whining yesterday.
[14:10:33] <mvita> you call that whining?
[14:10:40] <mvita> ;-)
[14:10:59] <wiesand> I juste wanted to see Spectre. Had to write the invitation, saw the mess...
[14:11:50] <wiesand> There are still a few really trivial ones I’d merge if they had a single +1.
[14:11:59] <wiesand> 12198
[14:12:17] <wiesand> 12207
[14:14:37] <kadukoafs@gmail.com/barnowl15A61B68> +1'd 12198
[14:15:03] <wiesand> 12126 is almost trivial
[14:17:37] <mvita> looking at 12207
[14:18:07] <kadukoafs@gmail.com/barnowl15A61B68> +1'd 12207
looking at 12126
[14:18:40] <meffie> +1 on 12198 and 12126
[14:19:23] <meffie> i can fix the inevitable nits on 12207 :)
[14:20:06] <wiesand> not p1
[14:21:02] <mvita> I was too slow.
[14:22:25] <wiesand> Thanks, that allowed flushing some of the queue.
[14:23:44] <wiesand> Mike, since 12126 was merged...
[14:24:26] <wiesand> I think 12173 could be abandoned?
[14:24:54] <meffie> oh, sorry for the duplicate.
[14:25:37] <wiesand> I’m thinking about rejecting 12179
[14:25:38] <meffie> abandoned the duplicate.
[14:25:42] <wiesand> Thanks
[14:26:38] <meffie> why?
[14:27:18] <wiesand> It touches files all over the place. Hard to get reviewed. Had lots of conflicts with the stuff rebased today.
[14:27:39] <wiesand> And it may fix a real problem, but hardly a new one.
[14:28:45] <meffie> well, the conflicts can be resolved easily.
[14:28:56] <meffie> i can rebase it now if you like.
[14:29:40] <wiesand> It has conflicts with several changes still in the queue which are simpler. Let’s at least wait for those.
[14:30:29] <kadukoafs@gmail.com/barnowl15A61B68> Oh, my ssh connection dropped; it's not that y'all were being quiet.
[14:30:41] <meffie> ok, which ones?
[14:30:44] <kadukoafs@gmail.com/barnowl15A61B68> I don't see a compelling need to get 12179 in right away.
[14:32:35] <meffie> it fixes shutdown problems, on solaris if i recall.
[14:32:50] <kadukoafs@gmail.com/barnowl15A61B68> That do not involve users doing silly things?
[14:33:15] <wiesand> I thought it fixes "umount/afs; afsd -shutdown"
[14:34:27] <kadukoafs@gmail.com/barnowl15A61B68> Sure -- "don't do that"
[14:34:31] <wiesand> ok, arguably 12197 isn’t all that important ;-)
[14:34:59] <meffie> i could be remembering wrong. i'll look.
[14:36:04] <wiesand> 11780 is another one that looks fairly straightforward
[14:36:13] <kadukoafs@gmail.com/barnowl15A61B68> (I'm a bit distracted for a bit)
[14:38:14] <meffie> 11780 is just backporting code changes from master?
[14:38:43] <wiesand> I think it was a clean cherrypick
[14:38:54] <wiesand> But that’s a while ago...
[14:39:14] <mvita> yes 12179 is fixing a panic whose root cause was a Solaris service management timeout on the first 'stop' causing a second 'stop' to be issued and run in parallel.
[14:41:15] <mvita> so yes, "don't do that" - the timeout was unreasonably short
[14:42:17] <meffie> ah, thanks remembering.
[14:42:47] <mvita> I still think this patch has value, but I don't think it's urgent for 1.6.18 if you want/need to defer to ease merges.
[14:43:11] <mvita> meffie:  memory had nothing to do with it, I looked it up
[14:43:17] <wiesand> In any case I want more +1s on it that the author’s
[14:43:20] <meffie> even better.
[14:43:33] <wiesand> than
[14:44:20] <wiesand> and it touches so many files there’s no point in rebasing it unless you’re sure it will be reviewed immediately after
[14:44:26] <wiesand> or it will clash again
[14:44:42] <mvita> looking at 11780
[14:45:38] <wiesand> it’s not urgent I agree
[14:46:54] <mvita> so for 12179 let's rebase it immediately after 1.6.8 and then review and merge it quickly
[14:47:00] <mvita> 1.6.18, sorry
[14:47:36] <wiesand> there may be a window shortly before 1.6.18pre too
[14:47:48] <mvita> ok
[14:47:50] <wiesand> which I hope we’ll get done next weel
[14:47:53] <wiesand> week
[14:48:21] <wiesand> what about "shake harder"?
[14:48:53] <wiesand> I think that was high on the wish list
[14:49:16] <wiesand> 11654
[14:50:04] <mvita> looking at 12193 - not familiar with 'hash'
[14:50:10] <meffie> 12206 got a +1 from ben.
[14:50:26] <meffie> perhaps i'll ask andrew to chime in.
[14:50:55] <meffie> since he was the one that pointed out a ref was needed.
[14:51:38] <wiesand> ah right
[14:52:18] <kadukoafs@gmail.com/barnowl15A61B68> (catching up)
[14:52:49] <wiesand> That’s good - I think we’re mostly done with 1.6 for today ;-)
[14:53:01] <kadukoafs@gmail.com/barnowl15A61B68> Okay then :)
[14:54:21] <kadukoafs@gmail.com/barnowl15A61B68> I sent a few things in the email ... Mike has been making a lot of
updates -- thanks!
[14:54:24] <meffie> 11654 also got a +1 from ben, which is encouraging.
[14:55:15] <wiesand> I’m afraid I’m not of much use regarding akeyconvert, 11349
[14:55:50] <kadukoafs@gmail.com/barnowl15A61B68> Yeah, 11654 is probably in good shape, I just wanted to think about it
more.  We could ask for Andrew's input, but I think it's simple enough
that we may not need to.
[14:56:10] <wiesand> On the ubik issue Jeffrey brought up: I wouldn’t call that data corruption
[14:56:21] <kadukoafs@gmail.com/barnowl15A61B68> (Mark: I'm only familiar with 'hash' because Anders made us use it in
Debathena :) )
[14:57:05] <mvita> it seems to do the same thing as 'which'
[14:57:23] <mvita> when would you use one over the other?
[14:57:35] <kadukoafs@gmail.com/barnowl15A61B68> So, are we just going to trust in Mike for akeyconvert review?
[14:57:47] <meffie> (oh, bash hash built-in. bash is too huge)
[14:58:04] <mvita> I'll look at akeyconvert
[14:58:07] <wiesand> zsh has it too
[14:58:38] <wiesand> ksh doesn’t
[14:59:09] <kadukoafs@gmail.com/barnowl15A61B68> Thanks
[14:59:36] <kadukoafs@gmail.com/barnowl15A61B68> That leaves Mike more time to work on externalize-log-rotation!
[14:59:51] <meffie> yes, mark is more trustworthy
[15:00:00] <mvita> but slower
[15:00:06] <meffie> yes, i do like fixing the logs.
[15:00:11] <mvita> 11349 reminds me of something I've been meaning to ask
[15:00:42] <mvita> this was  Nate's patch, but meffie's been uploading patchsets?
[15:01:27] <meffie> yeah, rude of me, but i just wanted it.
[15:01:33] <kadukoafs@gmail.com/barnowl15A61B68> The current gerrit acl allows any registered user to upload new
patches to any change, or nearly so.
[15:01:39] <mvita> I didn't know one could do that.
[15:01:49] <kadukoafs@gmail.com/barnowl15A61B68> I stopped worrying about being rude in this way a long time ago
[15:02:08] <mvita> ok.
[15:03:17] <mvita> <remembers Politenessman>
[15:03:27] <kadukoafs@gmail.com/barnowl15A61B68> Stephan: does that mean you want to leave the code as-is?
[15:03:50] <wiesand> er, which code?
[15:04:22] <kadukoafs@gmail.com/barnowl15A61B68> "allow ubik reads while writes are in progress", the thing that
Jeffrey was saying can cause data corruption
[15:04:58] <mvita> oh, that - I spent some time looking at that a few weeks ago
[15:05:01] <wiesand> No I didn’t mean that. It may be an actual problem which needs to be fixed.
[15:05:12] <kadukoafs@gmail.com/barnowl15A61B68> Ah.
[15:05:21] <wiesand> I just wouldn’t call it data corruption because the db doens’t get wedged, does it?
[15:05:26] <meffie> it effects master at the moment, not stable.
[15:05:27] <kadukoafs@gmail.com/barnowl15A61B68> You just mean that the data on the server is not corrupted, merely
that clients get bad copies sometimes.
[15:05:40] <wiesand> Right. A client malfunctions.
[15:05:56] <wiesand> And it’s metadata rather than data too.
[15:05:58] <meffie> it can be disabled on master easily, i'll push a patch.
[15:06:17] <wiesand> 1.6 is not affected because... lack of pthreading?
[15:06:56] <meffie> it's not called on 1.6. andrew did not include the changes on the stable branch to enable it.
[15:06:58] <kadukoafs@gmail.com/barnowl15A61B68> 1.6 is presumed to be rarely affected because of the use of LWP
instead of pthreading, yes.
[15:07:06] <kadukoafs@gmail.com/barnowl15A61B68> Or that, never mind.
[15:08:05] <wiesand> Not my turf, but ripping it out for 1.8 seems the right thing to do if it’s easy.
[15:08:08] <mvita> correct, the feature is present but not enabled on 1.6.x
[15:08:37] <meffie> so, the "allow reads while writes" is on by default in master. it could be made a run or build time option.
[15:11:02] <meffie> i'll take another look.
[15:12:35] <kadukoafs@gmail.com/barnowl15A61B68> Thanks.
[15:12:50] <meffie> no problem.
[15:14:06] <wiesand> Are we finished for today?
[15:14:15] <kadukoafs@gmail.com/barnowl15A61B68> That's probably a good enough chunk to break off for this week, and
we're over an hour anyway.
[15:14:19] <kadukoafs@gmail.com/barnowl15A61B68> Thanks, everybody!
[15:14:23] <meffie> thanks.
[15:14:30] <mvita> laster
[15:14:32] <mvita> later
[15:14:36] <wiesand> Thanks a lot for a productive meeting!
[15:14:39] wiesand leaves the room
[17:18:57] meffie leaves the room
[23:49:10] Jeffrey Altman leaves the room
[23:49:10] Jeffrey Altman joins the room