- Wednesday, February 18, 2015

release-team@conference.openafs.org

Wednesday, February 18, 2015< ^ >

Room Configuration

Room Occupants

GMT+0
[06:32:44] Jeffrey Altman leaves the room
[06:32:44] Jeffrey Altman joins the room
[10:15:49] shadow@gmail.com/barnowlE5B64A04 leaves the room
[10:16:01] shadow@gmail.com/barnowlE5B64A04 joins the room
[13:19:51] meffie joins the room
[14:58:42] wiesand joins the room
[15:00:45] shadow joins the room
[15:01:05] <wiesand> Hello from the Old World
[15:01:25] <shadow> hi
[15:01:43] <meffie> hello
[15:02:34] <shadow> i may vanish. i am trying to figure out why my ipv6 is losing. and i suspect somewhere along the way i am going to find myself offline :\
[15:03:01] <wiesand> Thanks for the heads up.
[15:03:13] kaduk joins the room
[15:03:50] <kaduk> Sorry I'm late.  This VM is inexplicably slow to do much of anything.
[15:04:00] <wiesand> Could we look at 11749?
[15:04:53] <kaduk> I suspect it's just "Ben is confused".
[15:05:16] <wiesand> Because that’s essentially what’s also in the NEWS update (11744), and because writing a release announcement without having understood this issue would be ... difficult.
[15:05:38] <shadow> 11749 is just confusing generally. i think chas is right but i don't promise it
[15:06:21] <kaduk> So, the RT ticket 131967 had Scripts running kernel 3.17.3-200.fc20.x86_64, which should be sufficiently new that it did not have the refcount leak on error, and the kernel was dropping the reference uniformly
[15:07:12] <kaduk> So, it sounds like Chas is right and the fix they needed was to grab the extra reference, and the bit where sometimes the reference was leaked on error did not apply to them.
[15:08:53] <kaduk> I removed my -1.
[15:10:10] <wiesand> Ok, thanks.
[15:11:22] <wiesand> I think we can proceed with pre2 then. No need to wait for 11749 - we can pull it up before pre3 or final.
[15:12:22] <wiesand> So I think we can just merge 11744 and 11709, then tag while Daria is still with us?
[15:12:53] <kaduk> Sounds like a plan.
[15:14:49] <wiesand> pullup of 11749 is ... 11752
[15:15:36] <shadow@gmail.com/barnowlE5B64A04> it's documentation. i marked it verified. merge if you wish
[15:15:52] <wiesand> on it...
[15:18:13] <shadow@gmail.com/barnowlE5B64A04> tag 617d424c6ce451445e93962a59c4880edc8502b9 as
openafs-stable-1_6_11pre2?
[15:18:35] <wiesand> Could you please tag 617d424c6ce451445e93962a59c4880edc8502b9 as openafs-stable-1_6_11pre2 ?
[15:19:35] <wiesand> So, yes, please :)
[15:19:39] <shadow@gmail.com/barnowlE5B64A04> have a tag
[15:19:44] <wiesand> Thanks.
[15:20:33] <wiesand> How about I roll tarballs and get it up to g.c.o while I watch you discussing 1.8 then?
[15:20:49] <kaduk> Seems reasonable.
[15:21:15] <kaduk> Did everybody look at my mail "towards a list of 1.8 release blockers" from last week?
[15:23:58] <shadow@gmail.com/barnowlE5B64A04> a lot has happened in my life since i looked
[15:24:30] <kaduk> I guess I can pick a subset to talk about
[15:24:45] <kaduk> 6947 is opr: Add new softsig implementation
[15:25:14] <kaduk> We are going to be shipping more pthreaded servers (ubik, in particular) in 1.8, so by that metric, we may be concerned about the failings of the existing softsig.
[15:26:07] <kaduk> On the other hand, I think the non-bos servers only care about signals for shutdown and log level, and in neither case is the loss of a signal a truly critical event.
[15:26:15] <shadow@gmail.com/barnowlE5B64A04> i'd punt on LinuxThreads and move on. the world has changed a lot
[15:26:24] <kaduk> (As opposed to for the bosserver, where losing a SIGCHLD is pretty bad)
[15:26:53] <kaduk> Do you think we should get this in for 1.8?
[15:27:58] <shadow> yes, but not so strongly that i think it blocks
[15:28:05] <kaduk> Okay.
[15:28:27] <kaduk> I'll skip 4972, since "if we have someone who cares about the OS X packaging, they will step forward"
[15:28:55] <kaduk> 10793, rx: Fixup BUSY packet callNumber
[15:29:45] <kaduk> I don't have a sense for how significant this issue is (clients retrying to create a call on the same busy channel)
[15:30:01] <kaduk> And Andrew is not confident about it, so I'm inclined to not spend time on it for 1.8.
[15:30:25] <shadow@gmail.com/barnowlE5B64A04> 10793: when we can bug simon for comment, sure, otherwise, wait
[15:31:05] <kaduk> I'm still uncertain how I feel about 10831 (Move LogDesWarning to common server code)
[15:31:57] <kaduk> Passing a logger function in BuildServerSecurityObjects just seems weird.
[15:32:35] <meffie> i think the log-des-warning is fine were it is.
[15:33:07] <shadow@gmail.com/barnowlE5B64A04> indiffferent
[15:33:25] <kaduk> Then there's 2591/11691 about the order in which locks are acquired for linux file lock processing.
[15:34:00] <kaduk> I don't really think it needs to be a release blocker, since there don't seem to be lots of people complaining about it.
[15:34:25] <shadow@gmail.com/barnowlE5B64A04> same
[15:35:01] <kaduk> Now, 11654 (libafs: shake harder in shake-loose-vcaches) does seem like a potential release blocker.
[15:35:13] <kaduk> On the other hand, the problem has been there for a long time...
[15:35:54] <meffie> it can be just a bug fix, not a branch blocker, imho
[15:36:25] <shadow@gmail.com/barnowlE5B64A04> once the rats next of comments are handled
[15:36:32] <kaduk> Fair enough.
[15:37:11] <kaduk> Mike, do you want the bos refactoring in 11599 and 11690 to be in 1.8?
[15:37:50] <kaduk> I guess the main point there is to allow startup even if it picks localhost as the primary address, or something like that.
[15:38:43] <meffie> yeah, this is a bug fix too. just to make setup more robust.
[15:39:34] <kaduk> We should meditate more on 11689 and get it in if we still feel good about it.
(ubik: SDISK_Begin no quorum, wrong db, no transaction)
[15:39:51] <kaduk> (along with 11738)
[15:40:51] <kaduk> Ah yes, 10227 (viced: prevent useless salvages when AFS config is invalid).  Am I wrong about VInitVolumePackage2?
[15:43:54] <meffie> wrong?
[15:44:13] <kaduk> Should we force a salvage if VInitVolumePackage2 fails?
[15:44:42] <meffie> offhand, i think so.
[15:45:19] <kaduk> Okay, I think that's what the current patchset does.
[15:45:45] <kaduk> (the current patchset has no reviews)
[15:46:06] <meffie> i dont no. i wish we didnt have to check the fs exit codes in bosserver.
[15:46:18] <meffie> * know
[15:46:46] <kaduk> I'm not sure how we could get out of that business, though.
[15:47:12] <wiesand> 1.6.11pre2 sources upload complete
[15:47:59] <kaduk> Anyway, from my list of "definitely or probably release blockers", we can remove 11654 (shake-loose-vcaches more harder), as being just a bugfix (but still work on it, of course)
[15:48:07] <kaduk> Yay tarballs
[15:50:20] <kaduk> So, that leaves the definitely/probably list as:
the ubik bits (11689, 11738)
9985 (allocate pathname buffers dynamically so as to not blow out the stack)
11639 (reject ChangeAddr on mh entries in vlprocs)
11638 (vos changeaddr needs -force to change mh entries)
jenkins hash for hash tables (11673, 11679)
[15:50:38] <kaduk> and 11734 (pioctl.c: restore required result variable)
[15:50:47] <kaduk> (forgot to ctrl+enter, there)
[15:51:20] <wiesand> I’ll wait a day or two with the announcement, just in case we’ll get some binaries soon. Those few eager to test tend to pick up (pre)releases without help anyway.
[15:51:57] <kaduk> There's also the items from the wiki page: document KeyFileExt and migration from 1.6 to 1.8 format, document that asetkey list works for KeyFileExt keys, remove vos release -stayup, and investigate lockless path through d_revalidate for potential issues
[15:52:07] <kaduk> Any volunteers to remove vos release -stayup?
[15:52:08] <meffie> btw, it old softsig is retired, does that mean we free up SIGUSR1 ?
[15:52:52] <meffie> that would be useful for the "external log rotation"
[15:53:29] <meffie> s/it/if the/
[15:54:02] <kaduk> It looks like we would, once consumers are migrated to the new version.
[15:55:42] <meffie> then i am all for getting rid of the old softsig
[15:57:13] <kaduk> I guess we can move the 11654 (shake-loose-vcaches) to the list of "might be release blockers", now:
11654 (shake-loose-vcaches)
6947 (new softsig)
encrypt everywhere by default (sort-of 11349)
11691 (linux file lock order)
11687 (avoid unsafe string functions while renaming BosLog to BosLog.old)
10789 (don't retry timed-out RW operations forever)
7896 (ptuser: guarantee that all names are valid C strings)
[15:59:04] <kaduk> No one is jumping up and down screaming in objection, so I guess that's a good sign...
[16:00:07] <kaduk> I'm still trying to get a handle for what's going on in 11741 et seq, trying to use asprintf from libroken in compile_et during the build.
[16:00:47] <meffie> is the issue that you want to remove libroken as a dep for compile_et?
[16:00:49] <kaduk> It seems like the way we use linker flags may be completely broken (i.e., only work by accident), since the arch flag -m64 is not getting passed to the static library build on 64-bit solaris
[16:01:11] <kaduk> I don't think we want to remove roken as a dep for compile_et; we want to add it.
[16:01:27] <meffie> oh.
[16:02:04] <kaduk> But that means we have to link it in statically, since the librokenafs.so is not usable during the build (absent not-really-portable linker tricks)
[16:02:48] <kaduk> And we're not building the static librokenafs.a properly, so the build is broken.
[16:03:27] <meffie> seems compile_et is just a build tool, so really shouldn't need libroken.
[16:03:46] <kaduk> The immediate change is a desire to use asprintf().
[16:04:37] <kaduk> So that we can use the full path to the input file even in a deep directory hierarchy, if I'm reading 9545 correctly.
[16:04:53] <kaduk> (This whole shebang was kicked off by Coverity complaining.)
[16:06:32] <meffie> ok, i see.
[16:09:51] <meffie> i agree fixing static libs is a good idea regardless.
[16:10:07] <meffie> (next?)
[16:10:10] <kaduk> Anyway, at this point mostly we just need to review the named patches (and merge things), and a few things need code tweaks.
[16:11:01] <kaduk> People should perhaps review my email from last week to double-check that I didn't miss anything important.
[16:12:08] <kaduk> Oh, and "how are those afs3-stds document updates coming?" ;)
[16:12:36] <kaduk> Hmm, Christof asks if we have a lint(1) config for our coding style.  I sort-of assume the answer is "no"...
[16:14:18] <Jeffrey Altman> sorry for being late.  lost network some point last night.  probably a delayed side effect of the ice storm
[16:14:20] <meffie> i am not aware of one. maybe shadow knows.
[16:15:06] <kaduk> Do you need the link to the log, Jeff?
[16:19:04] <kaduk> Anyway, do we want to talk about 1.6.12 today?
[16:19:40] <wiesand> I think it can wait for another week ;-)
[16:20:10] <kaduk> I don't think there are other 1.8 things to talk about.  "Go review some code instead" :)
[16:20:42] <wiesand> Unless there’s anything with potentially high impact anyone wants to push for 1.6.12. Such a thing we should discuss early...
[16:21:31] <wiesand> Thanks to your efforts, there seems to be a light at the end of the tunnel...
[16:21:53] <wiesand> 1.8 might happen /this/ Xmas after all ;-)
[16:22:47] shadow leaves the room
[16:23:05] <wiesand> Anything else to discuss today?
[16:23:14] <wiesand> Jeff, are you still reading up?
[16:23:32] <Jeffrey Altman> sorry, an emergency call came in
[16:23:53] <wiesand> want us to wait a few more minutes?
[16:24:38] <Jeffrey Altman> regarding lint.   I do not believe so.   There was an attempt early on (circa-2002?) to apply some uniformity to the tree via scripting.   The pretty print rules applied at the time are in the commit message
[16:25:23] <Jeffrey Altman> at this point the tree has diverged with different styles with different code imports.
[16:26:06] <Jeffrey Altman> I dislike committing reformatting patches because it make "git pickaxe" / "git blame" much less useful
[16:26:22] <wiesand> +1
[16:26:52] <kaduk> Yup.
[16:26:54] <Jeffrey Altman> re-1.6.12.   linux 3.20 (or 4.0 if that is what it is called) will require linux changes.   we are already broken there.
[16:27:32] <Jeffrey Altman> someone from YFSi will take care of vos -stayup
[16:27:34] <wiesand> Thanks for the heads up. That was my expectation though. Nothing unusual, sadly.
[16:31:15] <wiesand> I wonder how many know how dependent the linux client is on very very few people...
[16:31:55] <wiesand> In particular Marc.
[16:32:00] <Jeffrey Altman> regarding 10793.  The Rx BUSY packet issue is a side effect of the client and server getting out of sync due to the client giving up on a call that the server still has in progress.    10793 will mask the problem but it doesn't fix the root cause.
[16:32:57] <Jeffrey Altman> The end user community of any open source is completely unaware of who does the work, how much effort is involved, etc.
[16:34:13] <Jeffrey Altman> the other Rx changes that were merged should improve things.
[16:35:46] <kaduk> *nods*
[16:35:48] <Jeffrey Altman> unfortunately given the current architecture of the servers, they aren't able to cancel a call in progress when an abort is received from the client.  As a result the call channel will remain busy.
[16:39:27] <Jeffrey Altman> I think time is best spent performing reviews as Ben indicated earlier
[16:39:37] <wiesand> Ok, even if we’re not completely done for today, I have to leave.
[16:40:00] <wiesand> Thanks a lot everyone. I’ll send a draft announcement for pre2 to release-team a.s.a.p.
[16:40:09] <Jeffrey Altman> thanks
[16:40:21] <wiesand> Bye.
[16:40:29] wiesand leaves the room
[17:04:59] meffie leaves the room
[18:40:38] shadow joins the room
[22:05:27] kaduk leaves the room
[23:06:04] shadow leaves the room