- Wednesday, January 20, 2016

release-team@conference.openafs.org

Wednesday, January 20, 2016< ^ >

Room Configuration

Room Occupants

GMT+0
[04:46:16] mvita leaves the room
[14:10:49] mvita joins the room
[14:55:31] kadukoafs@gmail.com/barnowlFBAB7144 leaves the room
[14:55:43] kadukoafs@gmail.com/barnowlFBAB7144 joins the room
[14:58:19] shadow@gmail.com/barnowlABEE2063 leaves the room
[14:58:32] shadow@gmail.com/barnowlABEE2063 joins the room
[15:00:53] <mvita> hello
[15:02:04] wiesand joins the room
[15:02:28] <wiesand> Hi, sorry I’m late
[15:02:49] <wiesand> That colloq on quantum simulations was just too interesting
[15:03:48] <mvita> sorry I missed it!
[15:04:03] <wiesand> It’s not broadcast...
[15:04:09] <mvita> ;-)
[15:05:52] <wiesand> But the slides should later show up at http://physikseminar.desy.de/zeuthen/colloquia_in_2016/january_20_2016/
[15:06:21] <mvita> thanks
[15:06:34] <wiesand> So, any thoughts on Michael’s Linux 4.4 changes?
[15:07:31] <kadukoafs@gmail.com/barnowlFBAB7144> Hang on, let me sign in again to avoid receiving in quadruplicate
[15:07:36] <mvita> at first glance they look reasonable - didn't actually +1 yet because I wanted to look more closely
[15:07:39] kadukoafs@gmail.com/barnowlFBAB7144 leaves the room
[15:07:54] <mvita> and read what Chas had to say
[15:07:54] kadukoafs@gmail.com/barnowlFBAB7144 leaves the room
[15:07:54] kadukoafs@gmail.com/barnowlFBAB7144 leaves the room
[15:07:54] kadukoafs@gmail.com/barnowl7482D0F3 leaves the room
[15:07:59] <wiesand> With those we have the option to take them + the linux regression and call that 1.6.16.1 .
[15:08:26] <wiesand> Careful review ist still in order of course.
[15:08:39] <mvita> are they sufficient for 4.4 support as far as we know right now?
[15:08:50] kadukoafs@gmail.com/barnowl8DA8ED20 joins the room
[15:09:09] <wiesand> I’m told they are sufficient for getting it built.
[15:09:33] <wiesand> I’m trying to get the reporters to actually test them...
[15:09:42] <kadukoafs@gmail.com/barnowl8DA8ED20> I didn't look at the contents of Michael's changes yet.
[15:09:43] <mvita> okay
[15:10:24] <kadukoafs@gmail.com/barnowl8DA8ED20> I guess that some of the splice functions will now return ERESTARTSYS
if there is any signal pending in the current process, so fsync() and
maybe close() can now fail unexpectedly.
[15:11:07] <kadukoafs@gmail.com/barnowl8DA8ED20> (And maybe other things as well; I did not do original research.)
[15:11:55] <wiesand> So there’s more to it? :-(
[15:12:26] <kadukoafs@gmail.com/barnowl8DA8ED20> Well, the impression I get is that with the build fixes, it will work
reasonably most of the time.
[15:12:55] <kadukoafs@gmail.com/barnowl8DA8ED20> But someone would need to do some more investigation, stress testing,
or focused testing to really get a better sense of how serious the
issues are.
[15:13:30] <wiesand> Not likely to happen...
[15:13:47] <mvita> I'll see if I can get some support for doing some of that here
[15:14:22] meffie joins the room
[15:14:32] <mvita> yay meffie
[15:14:42] <meffie> sorry, was talking to marcio
[15:15:49] <meffie> he has a new opr function that does caching name lookups with res_query.
[15:15:59] <wiesand> If we release something with just those build fixes, testing will happen by the Ubuntu 16.04 users...
[15:16:22] <wiesand> opr... not for 1.6... :-(
[15:17:12] <kadukoafs@gmail.com/barnowl8DA8ED20> Hmm, not for 1.8, either, IIRC.
[15:18:12] <wiesand> Since I think there’s not much more to discuss regarding 1.6... want to go on about master/1.8?
[15:18:58] <kadukoafs@gmail.com/barnowl8DA8ED20> I haven't done anything for it this past week, unfortunately.
Working on the FreeBSD quarterly status report took up all my free
cycles.
[15:19:58] <kadukoafs@gmail.com/barnowl8DA8ED20> I guess we got some review on the issue where aggressive clangs
complain about our null checks for function arguments tagged as
nonnull.
[15:20:09] <kadukoafs@gmail.com/barnowl8DA8ED20> So that might be ready to go in now.
[15:21:18] <kadukoafs@gmail.com/barnowl8DA8ED20> There's still a bunch of stuff returned for "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:21:59] <kadukoafs@gmail.com/barnowl8DA8ED20> Most of them are at risk of getting left out if they don't get
updated.
[15:23:14] <meffie> ah, sorry, going to get back to my review backlog.
[15:23:16] <mvita> looking
[15:23:22] <mvita> uggg
[15:23:27] <mvita> yeah, sorry.
[15:24:04] <meffie> got a sensible gerrit dashboard now, that helps.
[15:24:13] <mvita> I've been heads-down on a difficult Solaris fix
[15:24:25] <mvita> but I saw some daylight on that last night
[15:24:39] <kadukoafs@gmail.com/barnowl8DA8ED20> I'd also request review on the rxgen-size-t-workaround topic if folks
are up for it.
[15:25:03] <meffie> ok
[15:25:08] <kadukoafs@gmail.com/barnowl8DA8ED20> But I don't know that I have a whole lot else to say for 1.8 this
week.
[15:25:12] <mvita> I can look at those today too.
[15:25:35] <kadukoafs@gmail.com/barnowl8DA8ED20> Thanks.
[15:26:06] <meffie> is the plan to kill the logging globals ok? or should that wait?
[15:26:09] <mvita> stephan: I haven't forgotten your backport, I intend to finish that today
[15:27:12] <kadukoafs@gmail.com/barnowl8DA8ED20> meffie: I have forgotten the details of what it looks like, so I'm not sure.
I think I support removing more of those globals, though.
[15:28:01] <wiesand> Mark: thanks
[15:28:02] <meffie> it would be like: 12168
[15:28:25] <meffie> instead of global flags, we pass a struct to OpenLog
[15:31:32] <kadukoafs@gmail.com/barnowl8DA8ED20> Skimming, seems like a reasonable interface. I wonder if it's worth
leaving a spare pointer in the struct in case we want to add
extensions in the future, but that's probably out of scope for this
meeting.
[15:32:18] <meffie> ok, thanks. i'll update for chas's comments then. and get back to the 'to review' dashboard
[15:32:45] <kadukoafs@gmail.com/barnowl8DA8ED20> Sounds good, thanks!
[15:33:51] <wiesand> "shake harder" needs more work?
[15:33:54] <meffie> oh, i had a 1.6 question. ben, should gerrit 12108 go into 1.6.17?
[15:34:29] <kadukoafs@gmail.com/barnowl8DA8ED20> I think so.
[15:35:02] <meffie> yes, for "shake harder" i'm doing andrew's second suggestion.
[15:35:36] <kadukoafs@gmail.com/barnowl8DA8ED20> (Er, I think 12108 should go to 1.6.x)
[15:35:48] <wiesand> yes 12108 makes sense for 1.6
[15:36:47] <meffie> ok, thanks. i didnt look to see if it could be cherry-picked or if it needs a backport.
[15:37:20] <meffie> thats all i got.
[15:37:43] <wiesand> [mumbles] that can be hard to distinguish :-(
[15:38:58] <kadukoafs@gmail.com/barnowl8DA8ED20> The RT ticket was from 1.6.9; I think it will be a pretty clean
cherry-pick.
[15:39:13] <meffie> cherry-pick was happy
[15:40:01] <kadukoafs@gmail.com/barnowl8DA8ED20> And IIRC the patch came from me source-diving to diagnose the RT
ticket.
[15:40:41] <meffie> gerrit 12172
[15:41:13] <meffie> oh shoot.
[15:42:14] <wiesand> Hmm??
[15:42:31] <mvita> looks fine to me
[15:43:03] <wiesand> shoot what?
[15:43:14] <mvita> "did not do the cherry pick dance?"
[15:43:42] <mvita> oh, right, I see it.
[15:44:11] <wiesand> ah, change-id issue
[15:44:19] <kadukoafs@gmail.com/barnowl8DA8ED20> No new change-Id?
[15:44:35] <meffie> yeah
[15:45:00] <wiesand> leather, rinse, repeat ;-)
[15:45:08] <mvita> HAH
[15:45:17] <mvita> leather indeed!
[15:45:53] <meffie> 12173, with new id
[15:50:25] <meffie> (you'd think the gerrit push would not be happy with the same id, oh well)
[15:54:16] <wiesand> It seems we’re finished for today?
[15:54:34] <meffie> yes, thank you!
[15:55:07] <kadukoafs@gmail.com/barnowl8DA8ED20> I think we're done for today, yup.
[15:55:18] <wiesand> Thanks a lot everyone!
[15:55:39] <wiesand> BYe
[15:55:41] wiesand leaves the room
[15:55:43] <mvita> bye
[16:55:43] meffie leaves the room