- Wednesday, August 17, 2016

release-team@conference.openafs.org

Wednesday, August 17, 2016< ^ >

Room Configuration

Room Occupants

GMT+0
[13:13:09] wiesand joins the room
[13:52:53] kadukoafs@gmail.com/barnowl2200C8CA leaves the room
[13:56:13] kadukoafs@gmail.com/barnowl2200C8CA joins the room
[14:00:12] <wiesand> Hello. Is anyone here?
[14:00:22] <mvita> stand by
[14:00:29] <mvita> we are finishing a mtg
[14:00:32] <wiesand> ah :)
[14:00:42] <mvita> (meffie and mark)
[14:05:29] <mvita> done
[14:05:54] <mvita> tx for the merges today
[14:06:05] <wiesand> Hope you had a nice vacation
[14:06:16] <mvita> and the review for getcwd, I'll fix those after our mtg here
[14:06:30] <wiesand> Yes I merged the trivial stuff today just to get it out of the way
[14:06:38] <mvita> vacation was too short - and rainy
[14:06:54] <mvita> and I injured myself, so I'm a little sore this week
[14:06:57] <wiesand> I think we’re going for 1.6.19 now, a 1.6.18.4 seems very unlikely
[14:07:08] <wiesand> Sorry to hear that!
[14:07:41] meffie joins the room
[14:07:46] <mvita> just pinged mike and joe
[14:07:54] <jhg> hallo
[14:07:54] <wiesand> 12340 is a fairly trivial one too, but I’d like to see another +1 besides the author’s before merging it
[14:08:04] <wiesand> Hi
[14:08:31] <mvita> then again, there's always this approach:  http://www.memegen.com/meme/iv6jqa
[14:08:41] <wiesand> Looks like the getcwd fix isn’t too far away?
[14:09:31] <mvita> did you have a chance to try it?
[14:09:41] <wiesand> not yet
[14:09:57] <wiesand> Like the meme. That grain of truth...
[14:10:33] <wiesand> I have very little time to dedicate to openafs currently :-(
[14:10:57] <kadukoafs@gmail.com/barnowl2200C8CA> Sorry I've been so inactive the past couple weeks; I've been a bit
under the weather and struggling to keep up with everything.
[14:11:31] <mvita> sorry.  we are really hoping you can try it for us - we are convinced it is correct but perhaps not sufficient
[14:11:40] <meffie> get well soon, dr kaduk
[14:11:42] <mvita> that's what your testing would show
[14:11:52] <Jeffrey Altman> 12340 is fine except for a style nit.  the braces should be avoided when the conditional applies to a single line of code.
[14:11:55] <mvita> sorry en
[14:12:17] <mvita> Ben
[14:12:56] <meffie> i sort of like the useless braces. they seem to help avoid bugs later.
[14:13:15] <mvita> ^
[14:13:26] <wiesand> or at least confusion
[14:13:54] <jhg> I prefer less text over more for the same meaning, generally.
[14:13:54] <wiesand> but if it’s the openafs style... but that change would have to go through master, as always
[14:13:56] <Jeffrey Altman> can you provide an example?
[14:14:14] <meffie> but lots of old c projects dont allow them, so it's understandable not to have them.
[14:14:27] <Jeffrey Altman> of where it avoids bugs later
[14:15:12] <meffie> i recall wiesand fixed one.
[14:15:17] <wiesand> 12254
[14:16:31] <jhg> so long as indentation is clear, braces are really irrelevant for reading code quickly
[14:16:36] <jhg> and correctly
[14:16:40] <meffie> yes
[14:17:43] <jhg> so
[14:17:47] <jhg> what is agenda for today
[14:17:51] <mvita> disagree - reading code quickly is precisely what makes braces important
[14:18:04] <jhg> mvita: agree to disagree =)
[14:18:27] <wiesand>     if (!(tdc->mflags & DFNextStarted))
        afs_PrefetchChunk(avc, tdc, credp, treq);
        afs_PutDCache(tdc);
}
[14:18:37] <jhg> indentation is incorrect
[14:18:49] <wiesand> exactly
[14:18:53] <meffie> yes.
[14:18:59] <jhg> so git commit hook lint
[14:19:02] <Jeffrey Altman> the indentation is off but that didn't result in a change in behavior
[14:19:04] <jhg> reindent
[14:20:24] <kadukoafs@gmail.com/barnowl2200C8CA> In the absence of 1.6 stuff, I could say a bit about 1.8 I guess
[14:21:00] <kadukoafs@gmail.com/barnowl2200C8CA> I didn't have enough focus to really look at the getcwd candidate fix,
but I've been trying to do some research into the questions on the
StaleVCache commit.
[14:21:05] <wiesand> Go ahead. Some of that would probably be potential 1.6 stuff too
[14:21:43] <jhg> pre-commit git hook: http://hastebin.com/alepufikoc
[14:22:14] <jhg> kadukoafs_gmailcom: where are you in your understanding of StaleVCache?
[14:22:26] <kadukoafs@gmail.com/barnowl2200C8CA> It's a shame that the various flags are not very documented, so we
have to do research to figure out the intended semantics.
Anyway, it seems that CVInit is only set during the initial vcache
population step (modulo darwin which also sets it in reclaim), so
there shouldn't really be any data associated with them that needs to
be flushed.
[14:23:15] <kadukoafs@gmail.com/barnowl2200C8CA> But, I didn't get to look at CVFlushed yet, though it seems like a
similar situation should hold.
[14:23:54] <kadukoafs@gmail.com/barnowl2200C8CA> Regardless of that, I'm still somewhat inclined to add another flag
that controls whether the CVInit|CVFlushed check is done, and a
separate commit that removes that flag, to keep the behavior change to
a minimum in the main commit.
[14:26:24] <kadukoafs@gmail.com/barnowl2200C8CA> But I don't think there's been much more activity than that.
[14:30:05] <jhg> hmmm
[14:30:41] <mvita> I have been planning to look at the dvhint topic but haven't been able to get to it
[14:30:48] <jhg> Perhaps leave some breadcrumbs for the meaning of various flags you find within the code
[14:31:45] <kadukoafs@gmail.com/barnowl2200C8CA> Yeah, I plan to put some comments in.
[14:32:06] <kadukoafs@gmail.com/barnowl2200C8CA> Any other topics?
[14:32:13] <mvita> I will schedule some time tomorrow
[14:32:50] <mvita> now on my calendar for tomorrow morning
[14:33:43] <wiesand> Is there any news on Linux 4.8 yet?
[14:34:14] <mvita> nothing new since last time we discussed it
[14:34:20] <jhg> I thought it was building and smoke tested on master
[14:35:14] <wiesand> Hmm, last thing I remember was something like  "will need some work, but nothing serious".
[14:35:25] jhg nods
[14:36:45] <mvita> joe, do you have some 4.8 patches then?
[14:36:57] <wiesand> No hurry. I think the right time for a 1.6.19pre1 would be around 4.8-rc5.
[14:38:33] <wiesand> A not quite trivial change which should go into 1.6.19 is 12339. But it needs review.
[14:39:21] <wiesand> Mike, what’s the rationale behind 12365 and 12366 ?
[14:39:25] <mvita> okay
[14:39:43] <meffie> oh, those.
[14:40:28] <meffie> they avoid build errors that can happen on linux.
[14:41:01] <wiesand> apropos, the fedora20 build slave seems to be awol
[14:42:26] <wiesand> 12357 is another one we’s probably want in 1.6.19. Not quite small, but mostly very simple.
[14:42:56] <jhg> mvita: just what is on gerrit for master
[14:43:40] <mvita> I'm not seeing them….
[14:43:43] <wiesand> I don’t think I’ve seen anything addressing Linux 4.8 there?
[14:44:34] <mvita> yeah, that's why I'm asking,  I thought you had submitted some but I don't see them
[14:45:19] <mvita> the time stuff
[14:46:01] <jhg> I thought there was a small build issue
[14:46:09] jhg looks
[14:48:21] <jhg> sorry, that was 4.7
[14:48:42] <jhg> I can do a fresh test of the ubuntu nightly
[14:49:18] <mvita> the following time APIs are not y2038 compliant and will not be made so - they are going away in 4.8 rc1:
    ⁃    Linux                replacement            OpenAFS usage
    ⁃    ================    ================    ========================
    ⁃    CURRENT_TIME         ktime_get_*            osi_UFSTruncate
    ⁃    CURRENT_TIME_SEC    current_fs_time_sec()    n/a
    ⁃    current_fs_time()        current_time()        n/a
    ⁃    timespec            timespec64            osi_Time, afs_osi_SetTime DEADCODE
    ⁃    inode->atime, mtime, ctime
    ⁃    afs_osi_Stat
    ⁃    vattr2inode
[14:49:26] <mvita> gah
[14:49:39] <mvita> "milk was a bad choice"
[14:51:36] <mvita> http://hastebin.com/bulavotuxo.coffee
[14:51:48] <wiesand> Is this the time to seriously consider 11716 ?
[14:54:03] <kadukoafs@gmail.com/barnowl2200C8CA> Any time is a good time to seriously consider 11716 :)
[14:54:11] <wiesand> So, no change? ("work to do, nothing serious")
[14:55:18] <wiesand> We weren’t quite sure whether it might still work on some platform and be in use...
[14:56:13] <wiesand> But if it helps avoiding hassle with the changes required for Linux 4.8, it’s probably time to axe -settime.
[14:56:20] <meffie> heh. yes.
[14:57:36] <wiesand> The only other items on the 1.6.19 wish list are probably the ubik fixes not yet merged on master.
[14:58:47] <wiesand> 12283 12289
[14:58:53] <Jeffrey Altman> I consider 11716 unrelated to the need to convert the 64-bit time within the afs cache manager.  That requirement is more closely related to the desire to convert to https://tools.ietf.org/html/draft-deason-afs3-type-time-03.   The afs cache manager has to track time for a wide range of reasons not the least of which are the atime, mtime, and ctime fields in the inode and the associated values in the vcache entries
[15:00:02] <mvita> agreed, I don't see a connection to 11716 either
[15:02:33] <mvita> Jeffrey, thanks for the pointer to the draft, I had forgotten all about that one
[15:02:34] <wiesand> You’re quite possibly right. Just saw the DEADCODE and remembered there’s some time related code still present on 1.6 but not master.
[15:04:26] <wiesand> Anything else to discuss today?
[15:05:11] <mvita> nothing more from me
[15:05:37] <wiesand> Let’s adjourn then. Thanks a lot for participating today!
[15:05:45] <mvita> thank you
[15:08:49] <jhg> ciao
[15:08:57] <wiesand> Goodbye
[15:08:58] wiesand leaves the room
[15:10:37] meffie leaves the room
[15:13:05] jhg leaves the room
[20:48:29] Jeffrey Altman leaves the room
[20:48:29] Jeffrey Altman joins the room
[22:13:02] mvita leaves the room
[22:14:54] Jeffrey Altman leaves the room
[22:20:19] mvita joins the room
[22:29:43] mvita leaves the room
[22:39:07] mvita joins the room
[23:06:59] mvita leaves the room
[23:49:06] Jeffrey Altman joins the room