[04:48:51] --- meffie has become available
[05:42:47] --- squinney has become available
[06:36:11] --- Marc Dionne has become available
[07:01:40] --- deason has become available
[07:03:28] <shadow@gmail.com/barnowl5ABA57FD> so what are the odds i can send
[07:03:38] <shadow@gmail.com/barnowl5ABA57FD> huh. i figured i'd get an error
[07:04:46] <squinney> Seems to work for you
[07:05:24] <shadow@gmail.com/barnowl5ABA57FD> yeah. so lacking stephan, do we have a plan? also curious why he
doesn't just get a jabber.openafs.org account to use
[07:06:49] <meffie> oh, maybe he doesnt know that is possible?
[07:07:53] <deason> well, going through 'agenda' items
[07:07:59] <deason> Any bug fixes coming up for 1.6.5 that may stop us from working on 1.6.6 now? When should we recommence merging onto the branch?
[07:08:26] <shadow@gmail.com/barnowl5ABA57FD> i know of no bugfixes that should hold anything back
[07:08:28] <deason> no problems with 1.6.5 I've heard of
[07:08:46] <shadow@gmail.com/barnowl5ABA57FD> all of the issues i have heard about have been kdc issues
[07:08:53] <meffie> havent seen any reports. seems to work for me.
[07:09:23] <deason> well also, most people haven't been hitting the relevant code paths, because setting it up isn't simple :)
[07:09:26] <squinney> 1.6.5 is working for us
[07:11:07] <deason> as for when to recommence merging... well, I would be okay with waiting another week, since the security items are keeping me quite busy right now
[07:12:02] <deason> but that's just for me, though I think stephan said he wouldn't have time for a week, either
[07:12:43] <deason> any other thoughts?
[07:14:13] <deason> well okay then
[07:14:18] <meffie> i think stephan want some sort of discussion on  changes for 1.6.6?
[07:14:22] <deason> moving on.... 'lost commits' not an issue, as mentioned on list
[07:14:28] <deason> getting to that
[07:14:38] <deason> next item: What are the "must have" bug fixes that should be included in 1.6.6?
[07:15:10] <deason> well, I'd like to fix that dasalvager mess
[07:15:59] <deason> and disable the rx busy retry thing that I remember talking about but don't remember seeing code for
[07:16:39] <deason> and change the client to afs_ClearStatus on any network error, not just idle
[07:17:32] <deason> (or maybe there was some other fix for the 'busy' thing, I don't remember right now)
[07:17:38] <Marc Dionne> 10043 fixes bos addkey and listkeys
[07:17:59] <deason> yes, that one is probably in the 'must have' list
[07:18:32] <meffie> yes
[07:18:35] <Marc Dionne> unless it's nod needed in 1.6
[07:19:17] <deason> iirc it is
[07:20:11] <deason> and.... well, there are a bunch of other bug fixes in the queue; I assume they'll go in, nothing particularly critical jumps to mind
[07:20:42] <deason> moving on if hearing nothing else....
[07:21:42] <deason> next item: Any changes due to Linux kernel changes we may have to push out soon?
[07:21:44] <Marc Dionne> linux kernel - 3.11 is at rc3, so roughly 5-7 weeks until release
[07:21:58] <Marc Dionne> master already has what's needed
[07:22:13] <deason> but 1.6 is missing things, I presume
[07:22:25] <Marc Dionne> yes, not pushed to 1.6 yet
[07:22:49] <Marc Dionne> 1.6 is currently ok up to 3.10
[07:23:13] <deason> I assume the commit messages all begin with "Linux 3.11:" so they're easy to find
[07:23:26] <deason> or will you submit them to 1.6?
[07:23:32] <Marc Dionne> yeah.  i think there's only a single commit actually
[07:23:43] <deason> ah, okay
[07:24:08] <deason> do you expect any other incompatibilities to arise from 3.11?
[07:24:25] <Marc Dionne> at this point, that would be versy surprising, so no
[07:25:02] <deason> okay, good, so moving on
[07:25:30] <deason> last item: Any potentially controversial changes you'd like to see in 1.6.6? Those should be discussed *now*.
[07:26:00] <Marc Dionne> and I run 3.11rc on several dev machines, so if there's new breakage i should be able to see it quickly and fix
[07:26:16] <deason> nothing controversial comes to mind for me right now
[07:26:18] <meffie> well, stephan said he'd like to see the unix fs flushall "feature"
[07:27:00] <deason> I think I'm okay with that; not too controversial
[07:27:54] <shadow@gmail.com/barnowl5ABA57FD> i'd like to giveupallcallbacks at shutdown
[07:28:16] <meffie> oh, yes.
[07:28:24] <deason> can you implement an on/off switch?
[07:28:39] <deason> (or I will / would like to, if I can find the time)
[07:29:36] <shadow@gmail.com/barnowl5ABA57FD> the issue is only what interface to use to do so. 
[07:29:59] <shadow@gmail.com/barnowl5ABA57FD> currently afsd does not make pioctls, but using a new afscall call for
it seems dumb
[07:31:03] <deason> I wouldn't object to e.g. sysctl, if there are enough platforms with analogous settings; since it's kinda internal/compatibility
[07:31:44] <shadow@gmail.com/barnowl5ABA57FD> aix, hpux, irix all lack such a thing, tho, i think
[07:31:51] <deason> alternatively, make either a new afscall for "compat stuff" (or try to reuse an existing one that sets various things, if one exists) or an fs command for setting compat flags
[07:32:34] <shadow@gmail.com/barnowl5ABA57FD> flags? well. i suppose we can hash something out in the gerrit ticket
or on openafs-devel or something
[07:33:36] <deason> I just mean, don't make it for "just this", though I suppose that may not matter and we can just add stuff to it later, even if we don't say it's for general "compat stuff" right now
[07:33:59] <deason> but, like the 'twiddle' call or pioctl or whatever it is; how it's just used for misc twiddling
[07:34:22] <deason> maybe it could go in that; or just have another call or pioctl for non-rx misc twiddling, or designate it for compatibility-related settings
[07:34:45] <deason> but enough of that here
[07:34:58] <deason> anything else? anyone else?
[07:35:59] <meffie> any objections to pulling up the volinfo.c changes for the "volscan" stuff? assuming i finish an push a man page?
[07:37:31] <deason> the only thing I may object to is if it still changes its behavior by detecting its called name
[07:37:53] <deason> I really think it should be changed to just be two different binaries
[07:38:12] <meffie> yeah, i agree, that seems better to just make 2 bins.
[07:38:33] <shadow@gmail.com/barnowl5ABA57FD> i'm indifferent. if the code is really common, make it a library (or a
separate source file) and skin it lightly twice, as 2 binaries
[07:38:35] <meffie> what do you think shadow?
[07:38:57] <meffie> ok
[07:38:59] <deason> otherwise no objections; it is desired by people, and if volinfo breaks, it's not exactly the most user-facing thing
[07:39:08] <meffie> yep.
[07:39:14] <deason> and it's easy to grab a volinfo from something else
[07:40:04] <deason> okay, anything else? anyone else?
[07:40:40] <shadow@gmail.com/barnowl5ABA57FD> nothing here
[07:43:23] <deason> okay, I assume that's it
[07:43:31] <deason> I'll try to compile minutes, unless someone else volunteers
[07:43:32] <meffie> ok, thanks.
[07:46:35] --- Marc Dionne has left
[07:58:05] <Jeffrey Altman> rt131709 should be addressed for 1.6.6
[07:58:21] <Jeffrey Altman> rt706131
[07:58:30] <Jeffrey Altman> oops, rt131706
[08:06:23] --- kaduk@mit.edu/barnowl has become available
[08:08:16] <kaduk@mit.edu/barnowl> Hmm, I bet I can send here, now.
(The MIT jabber server restarted.)
[08:19:43] --- squinney has left
[08:52:57] --- meffie has left
[09:52:49] --- m.meffie has become available
[09:53:47] --- m.meffie has left
[09:55:38] --- meffie has become available
[10:05:36] --- meffie has left
[15:33:08] --- deason has left