- Friday, December 22, 2017

release-team@conference.openafs.org

Friday, December 22, 2017< ^ >

Room Configuration

Room Occupants

GMT+0
[05:53:34] <kaduk@jabber.openafs.org/barnowl> I'm in the US pacific time zone this week, so may not be able to make
this week's meeting. Hopefully 1.6.22.1 is not waiting on anything else
from me!
[13:55:32] wiesand joins the room
[13:56:55] <wiesand> It's not, and it's done. The last missing item is the -announce moderators' approval.
[14:00:36] <wiesand> Hello. Who's actually here?
[14:01:39] meffie joins the room
[14:01:52] <wiesand> Hello Mike
[14:02:06] <meffie> hello.
[14:03:52] <wiesand> Misciting the famous football coach Sepp Herberger: "after the release is before the release"
[14:04:37] <wiesand> So: what next? 1.6.22.2 or 1.6.23?
[14:04:50] <meffie> 1.6.23pre1
[14:05:16] <meffie> in my opinion
[14:05:45] <wiesand> I guess it will depend on the readiness of the EL7.4 shakeloose stack.
[14:05:45] <meffie> thanks for 1.6.22.1!
[14:06:18] <wiesand> Well you guys wrote the code ;-)
[14:06:30] <meffie> andrew told me it was close, just trying to decide among alternatives.
[14:06:42] <wiesand> Sounds good, thanks.
[14:07:13] <wiesand> Still, we have 4 weeks to Linux 4.15
[14:07:39] <meffie> ok, Marcio is looking at the current build issue with 4.15rc.
[14:07:43] <meffie> h0
[14:07:47] <wiesand> And while we can probably wait a week or two longer, there's also the holiday season…
[14:08:17] <wiesand> speaking of 4.15, have a look at 12823 and 12824
[14:08:21] <meffie> (sorry the h0 was the cat walking on the keyboard.)
[14:08:42] <wiesand> np ;-)
[14:08:55] <wiesand> not worse than my typos anyway
[14:09:22] <meffie> ok, i will look at 12823 and 24
[14:10:31] <wiesand> those two changes make libafs build for me (unless I made more mistakes when preparing them - I'll test with patches pulled back from gerrit)
[14:10:53] <meffie> looks like those are the same patches marcio was doing yesterday :)
[14:11:20] <meffie> not sure, tho, i'll ask.
[14:12:13] <meffie> i'll try them with our linux-daily builder. i can give it gerrit numbersto try to build.
[14:12:27] <wiesand> that would be really nice
[14:13:02] <meffie> i wonder if i can set it up to build a gerrit number via the buildbot web interface...
[14:13:15] <meffie> i'm going to look into that.
[14:13:37] <wiesand> so I could trigger such builds myself? now that would be even nicer :)
[14:14:28] <meffie> yes, exactly. or anyone on the release-team
[14:15:26] <meffie> i'll see if it is doable.
[14:16:11] <wiesand> Well it's not that often that I submit actual code changes to the master branch…
[14:17:33] <wiesand> But I finally managed to contend for acinclude.m4 ;-)
[14:17:51] <meffie> yay! nice job ;)
[14:19:32] <meffie> but, again, there is no "merge conflict" here. gerrit is not honest. 23 is the parent of 24, so there's not a merge confict at all.
[14:20:02] <meffie> you can see from the sha1's 24 is based on 23.
[14:20:53] <wiesand> Yes, in this case there's absolutely no conflict. I was just too lazy to push them separately. And they are related after all
[14:21:26] <meffie> yes, for me, it's better to push them like this.
[14:21:49] <meffie> it's more like a git topic branch.
[14:22:19] <wiesand> But I bet there's more in the queue attempting to change acinclude.m4, and then all the others have to be rebased.
[14:22:43] <wiesand> Git can do it, gerrit would even allow it, but is configured not to.
[14:22:58] <wiesand> And I still think that "paranoid" setting is right.
[14:23:45] <wiesand> It's not as much a problem as it was a few years ago. Which is good and bad.
[14:25:17] <meffie> yes, as long as we rebase commits correctly it should not be a problem. most projects that use git do not maintain a linear history, and use merge commit every time.
[14:25:44] <wiesand> I really really like the linear history!
[14:26:07] <meffie> yes, non-linear makes the history really hard to understand, imho
[14:26:28] <meffie> esp for stable branches.
[14:27:28] <meffie> on non-openafs projects, i tend to use rebase when practical, and merge as needed.
[14:28:11] <wiesand> By now it seems unlikely that we'll have more attendees today. Adjourn? NB do you think there's any chance anyone would participate next week, or shall we cancel next week's meeting right away?
[14:29:32] <meffie> i will be available, but it is an SNA holiday so mark will be out. (Today is an sna holiday too, so that's why mark's absent today too.)
[14:30:50] <meffie> on the master/1.8.x front; the recent macos commits were merged.
[14:30:54] <wiesand> Ok, I'll be hanging out here, but won't expect much company
[14:31:06] <wiesand> to 1.8 already?
[14:31:45] <wiesand> No. NP, I can pull those up.
[14:31:56] <meffie> i think merged just to master. ok, thanks!
[14:32:12] <wiesand> We'll want them in the next release, no matter how many dots
[14:33:15] <meffie> also, some ubik fixes which are on master were submitted by marcio, i think intended for 1.6.23pre1
[14:34:37] <meffie> 12803, 6, 7, 11
[14:34:59] <wiesand> There are 5 more ubik changes already on the 1.6 queue. I'd still like a long prerelease phase, the longer the more of those.
[14:35:35] <wiesand> Which means ubik may have to wait another round.
[14:35:49] <meffie> we should ask andrew to review again. those fixes have been running for a long time in some places, which helps a lot.
[14:36:29] <meffie> also, we have to apply them when testing 1.6.x stuff.
[14:38:24] <meffie> so i hope they can be in a 1.6.23 release :)
[14:39:40] <wiesand> Convince me they're no risk.. preferably by getting lots of developers to +1 them…
[14:39:54] <meffie> sounds good!
[14:41:11] <meffie> thanks for pulling up the rpm spec file changes for linux debuginfo. i tested that one yesterday on centos7.
[14:42:23] <wiesand> Ah, good. (meanwhile I pulled it up to the 1.8 branch too, in fear of Ben's holy wrath)
[14:42:46] <meffie> lol!
[14:42:51] <wiesand> (I keep forgetting that we should do master -> 1.8 -> 1.6 now)
[14:43:04] <meffie> ah, yes, that's going to be unfun.
[14:44:35] <meffie> i dont think ben will mind rpm spec file changes :)
[14:46:23] <meffie> ok, i'll encourge people to review and test. We are running tests with the current set of "getcwd" changes on centos6 and 7 of various release levels.
[14:46:49] <wiesand> Good to hear that.
[14:47:26] <wiesand> My test capacities were mostly busy with 1.6.22, 1.6.22.1 and the SL packaging lately
[14:48:30] <meffie> oh, yes, 1.6.22. fun fun.
[14:48:31] <wiesand> But I hope to test getcwd next week. After all, my users are suffering from this issue.
[14:49:29] <meffie> i am sorry
[14:49:50] <wiesand> But it's not bad enough to rush out something that may make things worse.
[14:50:02] <meffie> ah! ok.
[14:51:01] <wiesand> And re 1.6.22, BTW we still have those reports from Jeffrey and dhowells warning about kafs potentially harming openafs in similar ways. Slightly worrying.
[14:51:53] <meffie> yes, there's a ticket about that, and i think it is something we will need to take on in january.
[14:53:10] <wiesand> There's a huge update to kafs in 4.15. If it becomes more popular, even if just for testing, we could be in trouble quickly, yes.
[14:53:19] <meffie> agreed
[14:53:49] <wiesand> Glad you say that :)
[14:55:27] <wiesand> Anything else? I ought tho throw myself into the pre-xmas shopping battle…
[14:55:29] <meffie> well, i guess the notes for the meeting will be short:) do you want to cancel next week?
[14:55:47] <meffie> (so i can put that in the notes?)
[14:56:13] <wiesand> As I said, I'll be here, but won't expect anyone to join.
[14:56:20] <wiesand> Thanks for those notes!
[14:56:33] <meffie> ok, Thanks!
[14:56:48] <meffie> merry christmas and happy new year
[14:57:06] <wiesand> Happy Holidays!
[14:57:14] wiesand leaves the room
[14:57:48] meffie leaves the room
[16:13:34] meffie joins the room
[16:38:20] meffie leaves the room
[16:38:21] meffie joins the room
[16:40:31] meffie leaves the room
[21:00:55] mvita leaves the room
[21:00:55] mvita joins the room