- Wednesday, July 20, 2016

release-team@conference.openafs.org

Wednesday, July 20, 2016< ^ >

Room Configuration

Room Occupants

GMT+0
[00:56:56] Jeffrey Altman leaves the room
[01:04:15] Jeffrey Altman joins the room
[05:56:21] Jeffrey Altman leaves the room
[05:57:19] Jeffrey Altman joins the room
[06:17:11] Jeffrey Altman leaves the room
[06:56:02] Jeffrey Altman joins the room
[07:47:35] kadukoafs@gmail.com/barnowl0226D601 leaves the room
[07:47:47] kadukoafs@gmail.com/barnowl0226D601 joins the room
[08:15:36] Jeffrey Altman leaves the room
[09:20:57] Jeffrey Altman joins the room
[13:25:33] meffie joins the room
[13:59:25] wiesand joins the room
[14:01:14] <wiesand> Hello
[14:02:26] <mvita> Hi!
[14:02:54] <mvita> things are hopping as usual
[14:03:22] <meffie> hello
[14:03:56] jhg joins the room
[14:04:18] <wiesand> So, I think the big question is "what next?"
[14:04:30] <wiesand> 1.6.18.3 or 1.6.19?
[14:05:09] <mvita> or the unmentionable
[14:05:35] <wiesand> This will depend on the states of: 1) Linux 4.7 2) re-enabling splice 3) 4) re-enabling shake-harder
[14:05:42] <wiesand> or that, yes
[14:06:12] <mvita> re-enabling splice has taken a back seat to the getcwd thing
[14:06:28] <mvita> joe has taken lead on getcwd w/ my continued assistance
[14:06:40] <kadukoafs@gmail.com/barnowl0226D601> Well, there's the ubik fixes that are imminent, which could go in a
1.6.19
[14:06:45] <mvita> (and mike's too - he came up with a good suspect this morning)
[14:08:02] <kadukoafs@gmail.com/barnowl0226D601> I guess the osx pkgbuild thing could go in a 1.6.18.3 and wouldn't
need 1.6.19.
[14:08:03] <wiesand> I pulled up RECFOUNDDB to 12339 an hour ago
[14:08:40] <wiesand> Right. pkgbuild + Linux would make a 1.6.18.3 if they’d be ready really soon.
[14:09:07] <wiesand> Otherwise, it’s time to work on 1.6.19 IMO
[14:09:18] <wiesand> or the unmentionable, but that’s up to Ben
[14:09:39] <kadukoafs@gmail.com/barnowl0226D601> The unmentionable is back on my radar, at least, though still no
progress.
[14:10:18] <kadukoafs@gmail.com/barnowl0226D601> Maybe one of these days I will actually try to track down why some of
gerrit's mails don't make it to me.
[14:10:22] <wiesand> So, I understand progress is being made on getcwd, but no ETA?
[14:10:23] <mvita> please let me know if you need any help from me
[14:10:48] <wiesand> Any news on Linux 4.7? That should be very close to final now?
[14:10:49] <mvita> my time will evaporate the first week in august, but then I should be open again
[14:10:56] <jhg> wiesand: when we have a cause, then ETA
[14:11:32] <jhg> wiesand: for 4.7, openafs does not build.
[14:11:47] <jhg> I have not had time to dig into those issues
[14:11:54] <kadukoafs@gmail.com/barnowl0226D601> "build failures are the easy bugs to fix" ;)
[14:12:27] <wiesand> not if another interface went GPLONLY or something...
[14:12:34] <jhg> they are, generally, easier yes =)
[14:13:39] <wiesand> what other ubik fixes would be for 1.6.x?
[14:14:06] <wiesand> NB RECFOUNDDB was not a clean cherry pick
[14:14:20] <kadukoafs@gmail.com/barnowl0226D601> The thing where if we have a majority of servers marked down we can
still return success to the client.
[14:14:41] <kadukoafs@gmail.com/barnowl0226D601> 12283 and/or 12289.
[14:15:40] <kadukoafs@gmail.com/barnowl0226D601> Interestingly, it seems that the code change in 12289 would be
sufficient
<phone call>
[14:16:18] <wiesand> Ok, thanks. I haven’t found time to look at changes not yet merged on master. But I’ll add those to my 1.6.19 candidate list.
[14:16:44] <kadukoafs@gmail.com/barnowl0226D601> 12289 would be sufficient to prevent the issue, but 12283 has some
aesthetic value as well.
[14:17:07] <kadukoafs@gmail.com/barnowl0226D601> And of course the long explanation from the commit message of 12283
should go in even if the code change does not.
[14:18:50] <kadukoafs@gmail.com/barnowl0226D601> I guess my current inclination is to hijack both changes, reverse the
order (and move the problem description to the now-first commit), and
tweak the rcode-setting logic slightly in 12283.
But there's potentially also the option of initializing rcode to
UNOQUORUM instead of what's in 12289 now.  I think I don't like that
as much, but definitely want more input.
[14:20:21] <wiesand> Would you consider this a 1.6.19 blocker?
[14:20:54] <kadukoafs@gmail.com/barnowl0226D601> Not especially; as Andrew notes, it's been around forever.
[14:21:02] <wiesand> ok
[14:21:13] <kadukoafs@gmail.com/barnowl0226D601> But we definitely know at least one thing that will fix it, and we're
just trying to decide which way we like best.
[14:21:28] <wiesand> could be worse then
[14:22:11] <meffie> usually andrew's way is the best (but not alwasys)
[14:22:27] <wiesand> I also pulled up a number of fairly trivial changes lately.
[14:22:36] <meffie> yes, thank you!
[14:23:05] <wiesand> And there are simple ones from before the last security release. 12259 is something that ought to go in soon IMHO.
[14:23:59] <wiesand> A bit more interesting ones: 12308 and 12328
[14:25:15] <kadukoafs@gmail.com/barnowl0226D601> Now I'm curious how the pullup to make 12339 was non-trivial, but you
should tell me after the meeting (or out-of-band).
[14:25:21] <wiesand> I also have 11599 from Mike’s wish list a while ago, and a note that it will need 11690
[14:26:20] <wiesand> 1.6 lacks a ubik locking change by Marc from 2011...
[14:26:31] <kadukoafs@gmail.com/barnowl0226D601> Ah.
[14:27:00] <kadukoafs@gmail.com/barnowl0226D601> It may be worth sending your list of changes to the list.
[14:27:16] <meffie> 11599 and a pony please.
[14:27:32] <wiesand> got it
[14:27:55] <kadukoafs@gmail.com/barnowl0226D601> Can I substitute a unicorn for the pony?
[14:28:03] <meffie> heh
[14:28:11] <mvita> NO SUBSTITUTIONS
[14:28:26] <wiesand> so we’ll do both, no problem
[14:29:26] <wiesand> That’s about what I have on my list of candidates for a next stable release.
[14:29:36] <mvita> all I want is a chat client that will take me to the gerrit item when I click on a number above
[14:30:21] <kadukoafs@gmail.com/barnowl0226D601> gs/\([0-0]{5}\)/https:\/\/gerrit.openafs.org\/\1/
[14:30:21] <jhg> I'm sure irssi could do it
[14:30:48] <kadukoafs@gmail.com/barnowl0226D601> Sigh, [0-9] of course.
[14:30:53] <meffie> thank you wiesand.
[14:31:32] <mvita> kaduk - what is the line you posted?  how would I use it?
[14:32:14] <kadukoafs@gmail.com/barnowl0226D601> It's approximately a sed command to turn a five-digit number into a
gerrit link.  But I don't know how to hook into any jabber clients to
apply such a thing, so it's not actually very useful.
[14:32:43] <mvita> oh.  thought it looked like sed.
[14:33:07] <kadukoafs@gmail.com/barnowl0226D601> The way Chrome's autocompletion works, I can type gerr<tab> in the URL
bar, followed by '/' and the number, which is low-enough-effort that I
haven't investigated something fancier.
[14:34:50] <mvita> oh, I bet I could do it w/ a "Service" (contextual menu) hook in OS X
[14:36:35] <wiesand> Back on topic, any other wishes/candidates for 1.6.19?
[14:37:07] wiesand leaves the room
[14:37:24] wiesand joins the room
[14:38:02] <meffie> there are more fixes on the way, but maybe not in time for 1.6.19.
[14:38:05] <wiesand> I’ll probably wait a while before starting to merge, but mark changes as approved which I would merge wasn’t there a possibility of a 1.6.18.3.
[14:38:18] <kadukoafs@gmail.com/barnowl0226D601> Seems reasonable.
[14:38:57] <wiesand> There are few conflicts so far, which makes this feasible.
[14:39:18] <meffie> excellent.
[14:39:25] <kadukoafs@gmail.com/barnowl0226D601> I can go make some changes to acinclude.m4 if you want...
[14:39:53] <kadukoafs@gmail.com/barnowl0226D601> ;)
[14:40:21] <mvita> afs_prototypes.h
[14:40:37] <wiesand> grin.. exactly the point: only one change to acinclude.m4 on the list yet
[14:40:52] <wiesand> not nearly as bad, at least in the past
[14:41:51] <mvita> I'd like to see 12291 and 12292 get some attention
[14:42:48] <mvita> should go in a 1.6.x eventually if/when approved for master
[14:43:25] wiesand leaves the room
[14:43:34] wiesand joins the room
[14:43:36] <kadukoafs@gmail.com/barnowl0226D601> "One-line patches; how important could they possibly be?" :-P
I'll take a look this week.
[14:43:38] <wiesand> Solaris only... would qualify for 1.6.18.3. "Just" get them reviewed and merged on master ;-)
[14:43:59] <mvita> depends on which line, Ben.... ;-)
[14:44:34] <kadukoafs@gmail.com/barnowl0226D601> Yeah, yeah.  "goto done"
[14:45:46] <wiesand> Is there more to discuss today?
[14:46:14] <mvita> nothing from me
[14:46:23] <wiesand> (I have to update my slides for tomorrow morning...)
[14:46:28] <kadukoafs@gmail.com/barnowl0226D601> 1.8, then?
[14:46:36] <wiesand> Fine
[14:46:42] <mvita> yay!
[14:46:57] <kadukoafs@gmail.com/barnowl0226D601> I sent an updated list of changes to the list.
[14:47:04] <meffie> thank you.
[14:47:32] <kadukoafs@gmail.com/barnowl0226D601> IT would be nice to get re-review on the chain starting at 11790,
since I just did mechanical updates at the commented locations.
[14:47:59] <meffie> alrighty.
[14:48:05] <kadukoafs@gmail.com/barnowl0226D601> I need to fix up 11793 after the rebase -- the tree built fine for me
on my mac ... which doesn't build the linux kernel module,
unsurprisingly.
[14:48:57] <kadukoafs@gmail.com/barnowl0226D601> And getting the fix for the "shake-loose harder"-triggered regression
is a key, of course, so thank you all for working on tracking that
down.
[14:49:27] <kadukoafs@gmail.com/barnowl0226D601> The only other thing listed as a blocker on that list is the ubik
issue of 12283/12289, that we mentioned previously.
[14:50:14] <kadukoafs@gmail.com/barnowl0226D601> Does anyone here want to comment on the merits of the different
approaches right now?
[14:52:39] <mvita> I've looked, but I need to read some code before commenting
[14:53:01] <kadukoafs@gmail.com/barnowl0226D601> Seems reasonable.  Rushing through ubik changes is not usually a good
idea, after all...
[14:53:13] <mvita> I'll do that when we are finished here
[14:53:18] <kadukoafs@gmail.com/barnowl0226D601> Thanks.
[14:53:53] <mvita> your idea of melding the best parts of the two into one commit sounds fine in principle
[14:53:57] <kadukoafs@gmail.com/barnowl0226D601> I guess that's it for the meeting, then, unless anyone else has
something?
[14:54:21] <jhg> I'm set
[14:54:46] <wiesand> Fine, let’s adjourn. Thanks a lot for your participation today!
[14:54:51] <mvita> thank you.
[14:54:57] <wiesand> cu next week
[14:55:01] wiesand leaves the room
[14:55:04] <meffie> thanks.
[14:55:07] meffie leaves the room
[22:09:08] mvita leaves the room
[23:28:14] mvita joins the room