- Wednesday, December 21, 2016

release-team@conference.openafs.org

Wednesday, December 21, 2016< ^ >

Room Configuration

Room Occupants

GMT+0
[03:05:06] mvita joins the room
[03:55:44] mvita leaves the room
[13:42:26] meffie joins the room
[14:59:16] wiesand joins the room
[15:00:02] <wiesand> Hi
[15:00:14] <kadukoafs@gmail.com/barnowlE45450E9> greetings
[15:00:46] <wiesand> 1.8.0pre1 is getting more attention than I had hoped for - congratulations
[15:01:01] <kadukoafs@gmail.com/barnowlE45450E9> It's exciting, yes, and thanks.
[15:01:03] <meffie> hello
[15:01:15] <kadukoafs@gmail.com/barnowlE45450E9> Too bad we didn't remember to fix the tests before releasing it, but
oh well.
[15:01:58] <meffie> it's my fault for not finishing the nightly builder to do a make-check.
[15:02:13] <wiesand> Assuming that there are no Linux 4.10 news yet, I have two items regarding 1.6.x today
[15:02:42] <wiesand> The first one is 12499 (32-bit s90 removal)
[15:03:03] <wiesand> Is this really the right thing to do in the stable series now?
[15:03:16] <meffie> yes, because that one fixes aklog
[15:03:28] <kadukoafs@gmail.com/barnowlE45450E9> I did a bit of looking to try to figure out the story behind 32- vs.
64-bit s390 and it was not terribly conclusive.
[15:03:37] <wiesand> on 64-bit s390?
[15:04:05] <meffie> we are using that patch on s390x so aklog works.
[15:05:20] <meffie> neale wrote the old process.s390x.s assembly for ancient versions of linux on the mainframe.
[15:05:47] <wiesand> Ok then. I guess we'll notice if this actually breaks anything still in use…
[15:05:59] <meffie> he has been using the default process.s for cleints running on linux on the mainframe.
[15:06:33] <meffie> he claims it will not break anyone. i asked several times.
[15:07:28] <meffie> i guess mainframes are too expensive to run unsupported linux versions on them ;)
[15:07:49] <wiesand> Fine then. Barring other objections that may be raised, let's include it in 1.6.21.
[15:08:04] <wiesand> My second 1.6 item is https://gerrit.openafs.org/#/q/status:open+project:openafs+branch:openafs-stable-1_6_x+topic:shake-harder
[15:08:08] <meffie> excellent, that will be helpful. thank you.
[15:08:49] <wiesand> There are a few path conflicts with other things on the wish list.
[15:09:14] <wiesand> Thus it would be helpful if we made up our mind about shake-harder.
[15:09:24] <meffie> i can rebase it after the others are merged, if that helps.
[15:09:57] <wiesand> It would help more to get it out of the way, one way or the other ;-)
[15:10:31] <wiesand> If we want it in 1.6.21, let's work on getting it merged. If not, let's abandon the stack?
[15:11:08] <meffie> well, there are a number of sites that need the cache manager to give up memory it is not using ;)
[15:11:48] <wiesand> On the other hand, those would get an extra incentive to help getting 1.8.0 ready for prime time ;-)
[15:11:52] <kadukoafs@gmail.com/barnowlE45450E9> The only thing that would make me hesitate to put it (back) into 1.6.x
is that there's this other call to d_invalidate() and I'm not sure we
afs_linux_dentry_revalidate() determined whether it needed to be
converted as well.
[15:12:34] <kadukoafs@gmail.com/barnowlE45450E9> But otherwise I think we claim that we fixed the issues it exposed the
first time, so it should be able to go back in.
[15:14:01] <meffie> i think that makes sense.
[15:15:05] <wiesand> So let's try to get them into 1.6.21pre1
[15:15:14] <wiesand> review review review…
[15:15:25] <meffie> ok, thank you.
[15:15:48] <meffie> and in this case, stress tests would be helpful.
[15:17:11] <kadukoafs@gmail.com/barnowlE45450E9> Is there anything else we want to talk about for 1.6.x?
[15:17:11] <wiesand> The next thing on the 1.6 wish list is probably Solaris 11 PAGs
[15:17:33] <wiesand> But some of those still aren't merged on master.
[15:17:52] <wiesand> But that's it regarding 1.6.x today from my point of view
[15:18:27] <meffie> thanks wiesand, yes, solaris 11 pags would be helpful.
[15:18:34] <kadukoafs@gmail.com/barnowlE45450E9> Ah, 11979?  It keeps being bigger than I expect when I go to try
reviewing it :-(
[15:18:48] <meffie> (solaris 12 is supposed to be coming soon too)
[15:19:26] <wiesand> yes, that one
[15:19:45] <kadukoafs@gmail.com/barnowlE45450E9> (But it looks like I did make some comments on it, at least...)
[15:20:09] <wiesand> I didn't blame you specifically
[15:20:18] <meffie> lets see, this was andrew's patch. i can make updates for him.
[15:20:55] <wiesand> Thanks.
[15:20:56] <meffie> thanks for pointing out the comments.
[15:21:25] <wiesand> I also still have 10245 in mind for 1.6.x. But again, path conflicts…
[15:21:26] <kadukoafs@gmail.com/barnowlE45450E9> From the 1.8 side, I think we understand the various test failures now
and probably know which fixes are going to go in, but they needed a
bit more review before merging.  (Just me would probably be enough,
but I was busy this weekend -- time with the in-laws.)
[15:22:34] <meffie> it's nice to see someone else running the tests :)
[15:23:14] <meffie> i'm open to a better way to do 12379.
[15:24:05] <meffie> do we really want to change the jhash to make the results endian independent? that seems to be asking for trouble.
[15:24:29] <meffie> (on 12493)
[15:24:57] <kadukoafs@gmail.com/barnowlE45450E9> w.r.t. https://rt.central.org/rt/Ticket/Display.html?id=133588 if
anyone has a suse machine handy with swig, it might be worth trying to
figure out why swig is crashing.  (But then again it might not.)
We should probably give a configure option to not even try, though.
[15:26:41] <kadukoafs@gmail.com/barnowlE45450E9> Well, w.r.t. endianness, we'd have to (re)convince ourselves that this
stuff is never hitting the network, or possibly even disk.
[15:28:44] <kadukoafs@gmail.com/barnowlE45450E9> So, maybe we don't want to change the hash behavior for big-endian
machines, but I also am not very excited about having the test suite
depend on the endianness.
[15:29:29] <kadukoafs@gmail.com/barnowlE45450E9> I guess we could try to microbenchmark the hash changes on
both big- and little-endian systems and see if it changes.  (IIRC,
Anders said that at -O2 gcc generated the same instructions on amd64.)
[15:31:14] <meffie> well, maybe some testing on hash distribution and speed would be helpful.
[15:32:47] <meffie> having on hash that gives the same results on both big and little endian would be nicer.
[15:32:59] <meffie> having one
[15:36:19] <kadukoafs@gmail.com/barnowlE45450E9> *nods*
[15:36:39] <kadukoafs@gmail.com/barnowlE45450E9> Have you had much luck trying to convince people to test 1.8.0pre1?
[15:37:20] <meffie> not yet. seems to be a lot of end of year projects going.
[15:37:51] <kadukoafs@gmail.com/barnowlE45450E9> Understandable.
[15:38:05] <wiesand> Site wide power outage Jan 3 …
[15:38:48] <kadukoafs@gmail.com/barnowlE45450E9> That sounds exciting
[15:38:49] <meffie> i made some changes to src/packages/RedHat/openafs.spec.in to build 1.8.0pre1 rpms for myself.
[15:39:08] <kadukoafs@gmail.com/barnowlE45450E9> Hmm, I wonder how they compare to what billings has
[15:39:25] <meffie> i think billings would be much nicer ;)
[15:39:31] <wiesand> The very core may survive on UPS while they're working on the power… or not
[15:39:34] <kadukoafs@gmail.com/barnowlE45450E9> (ISTR billings saying something about having test builds, but maybe
I'm misremembering and it was just intent to make some)
[15:40:33] <meffie> i know we want to have packaging "downstream", but it is nice to have "contributed" packaging in tree.
[15:42:00] <wiesand> Stephen may well pick it up… let me check…
[15:42:40] <wiesand> Not yet
[15:43:27] <kadukoafs@gmail.com/barnowlE45450E9> Anyway, I don't think we have more concrete things to talk about for
1.8
[15:43:42] <kadukoafs@gmail.com/barnowlE45450E9> review/test as you can
[15:43:55] <meffie> ok, thank you. have a nice holiday.
[15:44:41] <kadukoafs@gmail.com/barnowlE45450E9> Yes, happy holidays everyone
[15:44:56] <wiesand> Happy holidays!
[15:45:14] wiesand leaves the room
[15:46:21] meffie leaves the room