- Wednesday, June 11, 2014

release-team@conference.openafs.org

Wednesday, June 11, 2014< ^ >

Room Configuration

Room Occupants

GMT+0
[06:12:21] Jeffrey Altman leaves the room
[06:12:23] Jeffrey Altman joins the room
[09:15:06] wiesand joins the room
[09:16:20] <wiesand> test
[13:57:09] Marc Dionne joins the room
[13:57:27] meffie joins the room
[14:00:38] <wiesand> Hello
[14:01:29] <shadow@gmail.com/barnowlC1E71073> hi
[14:01:29] kaduk joins the room
[14:01:39] <Marc Dionne> howdy
[14:01:47] <kaduk> 'mornin'.
[14:02:13] <Jeffrey Altman> present
[14:02:31] <wiesand> Thanks for being here.
[14:02:36] <wiesand> Marc, any bad surprises in the final Linux 3.15?
[14:02:52] <Marc Dionne> nope, everything still looks ok
[14:03:06] <wiesand> And how's 3.16 doing?
[14:03:10] <Marc Dionne> and current 3.16 in merge window is still ok, no vfs changes yet
[14:03:43] <wiesand> Do you see a chance that we won't have anything to deal with before 3.17?
[14:04:19] <Marc Dionne> i expect the changes that were in -next to shop up, which mean minor changes.  al viro is just usually late in pushing his vfs changes
[14:04:28] <Marc Dionne> s/shop/show
[14:04:48] <wiesand> "minor" sounds good. Thanks.
[14:05:19] <wiesand> Has anyone tested RHEL7 final yet?
[14:05:44] <Marc Dionne> there is a dentry related series from Bruce Fields to keep an eye on, but hasn't been picked up yet.  i don't currently expect it to make 3.16
[14:06:08] <wiesand> Good.
[14:06:10] <Marc Dionne> rhel7 final is very close to rc, not many packages are different
[14:06:38] deason joins the room
[14:06:49] <Marc Dionne> haven't actually tested but i'd be surprised if there are new issues
[14:07:00] <wiesand> I downloaded it, but had no chance to look at it yet. Will do asap.
[14:07:41] <wiesand> But we have that open question whether we should continue to provide binaries for new Red Hat releases.
[14:07:47] <wiesand> And if so, which ones.
[14:08:55] <wiesand> The RHEL7 atomic thing is not yet ready, I think. But once it is, our existing packaging won't work for that.
[14:09:34] <deason> and I thought we had raised the possibility of switching to non-transarc paths for the next rhel, if we are continuing to provide packages
[14:09:58] <wiesand> That was one of them, yes.
[14:10:30] <wiesand> But then, why not simply use the RPMFusion ones?
[14:12:13] <deason> yeah, I am "pro" use-other/existing-packaging
[14:12:28] <deason> those are non-transarc, yes?
[14:15:04] <wiesand> I think so, but tried verify right now, and can't find them.
[14:15:05] <Jeffrey Altman> I'm quite sure they are non-transarc.
[14:15:48] <Jeffrey Altman> When Jack Neely developed the packaging he did so because " I needed OpenAFS packages that conformed to the Filesystem Hierarchy Standard (FHS). Secondly, the current OpenAFS packages use an older kmod standard for supporting kernel modules in Fedora/RHEL, and I needed the more recent kmod standard to integrate with the other kernel modules I deal with."
[14:16:21] <wiesand> I think Jack's are the ELRepo ones.
[14:16:41] <Jeffrey Altman> http://lists.openafs.org/pipermail/openafs-info/2010-June/033907.html
[14:18:20] <Jeffrey Altman> Jack is no longer employed at an AFS using shop and I do not believe he is currently maintaining anything
[14:19:34] <Jeffrey Altman> Ken Dreyer is the current maintainer for RPM Fusion
[14:21:25] <wiesand> Right. I just can't find RHEL packages there, just Fedora ones...
[14:21:40] <wiesand> I think I'll ask Ken by PM.
[14:21:41] shadow@gmail.com/barnowlC1E71073 joins the room
[14:22:33] <Jeffrey Altman> http://elrepo.org/tiki/kmod-openafs has RHEL packages for OpenAFS.   I believe those were also produced by Jack Neely
[14:22:36] shadow@gmail.com/barnowlC1E71073 leaves the room
[14:22:44] <kaduk> What's the next agenda item?
[14:23:51] <wiesand> The ELrepo ones do thinkgs with the kmod the openafs developers say are wrong and dangerous.
[14:24:38] <wiesand> The next agenda item is 1.6.9 :-)
[14:25:30] <kaduk> "We should have one."
[14:25:59] <shadow@gmail.com/barnowlC1E71073> sure, why not
[14:26:08] <meffie> ha
[14:26:24] <wiesand> Pre1 should probably wait until we have more confidence in what Linux 3.16 will look like.
[14:26:59] <wiesand> So, there's a bit of time, but there are lots of open changes too.
[14:27:28] <wiesand> I sent around a list of what I think could go in and is available in gerrit for 1.6 already. Many need review.
[14:27:35] <kaduk> I was just looking at 11211 and deciding that it's too complicated to review during the meeting.
[14:28:25] <deason> yes, I think that's the one I skipped when looking over changes
[14:28:39] <deason> I wasn't clear on if any fix or new functionality required that
[14:29:02] <wiesand> I tried to group them a bit, and was hoping we could find agreement on whether they're welcome at all.
[14:29:19] <meffie> if we are going to pullup cmd changes, i'll need to rebase the volscan patches again.
[14:29:24] <wiesand> 11211: The reason I looked at cmd is at the end of the stack.
[14:29:41] <wiesand> (11213)
[14:29:51] <wiesand> er, 11214
[14:30:33] <deason> 11214? a one-line change?
[14:31:55] <wiesand> Well, try to apply the master version to 1.6.
[14:33:48] <deason> I can just apply it by hand :)
[14:34:45] <wiesand> You can. But everytime these things are done, they make it harder to apply the next change. Which may not be that simple.
[14:35:28] <wiesand> But if everyone else thinks that's nonsense, you're probably right.
[14:35:53] <deason> it's not "nonsense"; I just don't think it's worth it in this particular case
[14:36:41] <deason> I understand that you want to pull in big changes like this so we're not looking around for all of the required changes 10 months from now, but I'm not sure that change will ever go in 1.6
[14:36:55] <deason> since I was not expecting the larger refactoring/retooling of libcmd to go in
[14:37:36] <deason> so, I wasn't expecting other changes to libcmd itself; that could be wrong, of course, but it may not be
[14:38:21] <wiesand> This one-liner is one that makes sense.
[14:38:47] <deason> yes
[14:38:48] <meffie> i think this one does, if we also include he man page updates.
[14:39:03] <wiesand> Obviously, there's nothing urgent about it. Feel free to -1 such things if you feel they don't belong into 1.6.
[14:40:11] <kaduk> I guess I'm still on the fence about whether it belongs in 1.6.
[14:41:20] <wiesand> That's fine. Me pulling up a change doesn't mean I'll insist on it going in.
[14:41:39] <wiesand> It's really more a genuine question what others think about it.
[14:43:16] <meffie> including small fixes from new contributors can help encourage future fixes :)
[14:43:26] <wiesand> The next group is the remaining coverity ones: 11014+11206 and 11196
[14:45:03] <wiesand> The two from the original stack removing the MRAFS remnants should probably be abandoned. Jeffrey objects to them, and he's probably right.
[14:45:53] <wiesand> Mike: yes. And frankly, I have to practice this git/gerrit stuff occasionally...
[14:46:26] <kaduk> Do you have the numbers for the MRAFS ones handy?
[14:46:35] <Jeffrey Altman> In general I believe that feature changes should go in subsequent 1.x releases.   The volscan/volinfo changes are to a debugging tool that is not used by the majority of users and is sort of on the side.   We have consensus that pulling that up is reasonable because it isn't core.
Pulling up the libcmd rearchitecture changes is wrong to me because it introduces change where overall it is not required.
[14:47:05] <wiesand> Ben: 10865/6
[14:47:06] <Jeffrey Altman> The "show version" change can be re-implemented for 1.6 without requiring all of the other changes on master.
[14:47:48] <wiesand> Thanks for the input.
[14:48:11] <wiesand> Another change you voiced objections to in general is the parallel make stack...
[14:49:16] <wiesand> 1.6 currently doesn't need it. But not taking it makes the skew worse.
[14:49:25] <Jeffrey Altman> I would like to see openafs move to a new release series based off of master.    Then we don't have to worry about pulling stuff up and version skew.
[14:49:36] <kaduk> Oh, hmm, do I need to pull up the toplevel venustests target? Let me check...
[14:49:53] <kaduk> Well, since you mentioned it<more>
[14:50:07] <wiesand> Jeffrey: Right, that's what I'd prefer too.
[14:50:25] <kaduk> I'm travelling for the next two weeks, but I was probably going to push for cutting a new stable release branch from master when I get back.
[14:50:53] <meffie> most of the parallel-make patches just add missing deps, and some minor makefile fixes here and there.
[14:51:19] <Jeffrey Altman> I don't have general objections to fixing parallel make issues.
[14:51:57] <Jeffrey Altman> obviously master and 1.6 have significant skew between the two because of all of the libtool changes
[14:51:57] <meffie> for beyond 1.6.x, i'd like to see if we can generate deps, etc.
[14:52:06] <wiesand> There are no parallel make issues in 1.6 ;-) Or at least they're extremely rare.
[14:52:13] <meffie> they are masked.
[14:53:25] <wiesand> So, no general objections to the parallel make stack. Fine.
[14:53:38] <wiesand> Stack reduction probably doesn't need discussion?
[14:54:21] <wiesand> I'm a bit concerned about the performance impact of all those tiny mallocs/frees/
[14:54:56] <wiesand> But it may not be a real issue.
[14:54:59] <Jeffrey Altman> it is a valid concern.   it would be good to have some numbers
[14:55:52] <Jeffrey Altman> for the code paths in question, what operations are required to exercise them.   what time does it take to perform N operations with and without the change
[14:56:44] <wiesand> Most of them happen inside the kernel module, right?
[14:57:01] <kaduk> The motivation is to reduce kernel stack usage, yes.
[14:57:39] <wiesand> Which makes it hard to get those numbers.
[14:58:21] <wiesand> Ben: yes, the venus/tests one was missing. Thanks.
[14:58:34] <kaduk> Similar code paths should be present in ukernel.
It is possible to time filesystem operations from userspace and rely on statistics to average out other fluctuations.
[14:59:18] <kaduk> venustests did not cherry-pick cleanly, but it was easy to resolve.
[15:00:36] <wiesand> It path conflicts with others already present, so will need to be rebased. But it's easier to remember now.
[15:00:50] <kaduk> Yup.
[15:01:17] <wiesand> How about those "avoid duplicate messages" changes from Perry?
[15:01:25] <wiesand> 11181..3
[15:01:37] <kaduk> I guess I should actually look at those...
[15:02:43] <wiesand> They look more complicated than the cmd stuff to me.
[15:02:50] <kaduk> (But our discussion here should not wait on that, as they are non-trivial to review.)
[15:03:16] <kaduk> They are also more useful from a user-visible standpoint than the cmd stuff, if I understand correctly.
[15:04:11] <Jeffrey Altman> I am fine with 11181..3
[15:04:38] <wiesand> Ok.
[15:05:01] <Jeffrey Altman> Perry addressed my concerns in 10942
[15:08:02] <wiesand> 11158 and 11205 can certainly go in after sufficient review, I think.
[15:08:44] <kaduk> I added Anders as a reviewer on 11205 just a few minutes ago.
[15:09:10] <wiesand> Yes, this would obsolete the change proposed by him.
[15:10:16] <wiesand> Ok, it seems we agree to accept everything but the cmd stack for 1.6.9.
[15:10:31] <wiesand> After proper review of each change, of course.
[15:11:02] <wiesand> And I thinks that's enough churn for a release.
[15:11:03] <kaduk> I have been testing my rxgk code on some debian VMs recently (for various reasons), and the kernel module build setup on master is definitely suboptimal.
[15:11:56] <wiesand> Due to 11186?
[15:12:50] <kaduk> I haven't been sufficiently annoyed to debug exactly why files in MODLOAD are being compiled every time I run make or make install, yet.
[15:13:57] <meffie> we dont have good dependencies, so we just rebuild all the time.
[15:15:04] <meffie> but i dont think 11186 makes that worse, does it?
[15:15:45] <kaduk> I don't see how it would, just looking at the code.  Maybe I'm just running into what you described in your 11:13:57.
[15:17:39] <wiesand> I'd like to go back to the "next stable branch" topic.
[15:17:48] <wiesand> How to make it happen?
[15:19:13] <shadow@gmail.com/barnowlC1E71073> "git checkout origin/master; git branch openafs-stable-1_8_x; git push
-u gerrit openafs-stable-1_8_x"
[15:19:20] <shadow@gmail.com/barnowlC1E71073> well, i guess you can't push a branch
[15:19:39] <wiesand> Probably not.
[15:19:56] <wiesand> But others can. Why don't they do it?
[15:19:57] <shadow@gmail.com/barnowlC1E71073> "you" can't. (i don't think i can at the moment either)
[15:20:14] <Jeffrey Altman> There is some gerrit and buildbot configuration that needs to be setup but cutting the branch isn't hard.
[15:21:02] <Jeffrey Altman> Ben probably has the best idea of what needs to be fixed/finished on master at this point
[15:21:45] <Jeffrey Altman> raise of hands.   anyone here running clients or servers built from master?
[15:22:00] <wiesand> No.
[15:22:01] <kaduk> I haven't run into anything especially egregious other than the call refcount issue, but I'm also not stressing the machines a whole lot.
[15:23:10] <Jeffrey Altman> no libtool issues?
[15:23:30] <Marc Dionne> i test the master client probably every few weeks or so.  haven't tested the servers in a long time
[15:23:35] <kaduk> There have been libtool issues, but I think I can work around them.
[15:24:47] <kaduk> There are probably some surprises lurking on the platforms I can't test on, though :)
[15:25:19] <Jeffrey Altman> we can either fix them on master now or wait until the branch is cut.   I would prefer to see them fixed now
[15:26:06] <kaduk> The only libtool things I remember offhand relate to symbols that are only present when rxgk is enabled, and how to best deal with that; I went through a few iterations of workarounds.
[15:27:03] <kaduk> The current thought is to make the library build rules look in the object directory for a symbols file and use that if present, otherwise use one from the source directory.  That lets me have configure output the files that need to change, and not need to have all of the symbols files be generated files.
[15:28:33] <kaduk> 11281 is the library build rule change.
[15:28:40] <deason> why not just have all of them be generated?
[15:29:27] <kaduk> It's a bigger patch.  I think Chas was not very keen on having them be generated, but maybe that was just having them be generated by make instead of configure; I'd have to go back and look.
[15:31:37] <kaduk> But apparently I am completely misremembering his comments on 10590.
[15:32:19] <deason> er no, for some reason I was thinking it would be confusing to depend on an objdir .sym existing, but you wouldn't have both a srcdir and objdir .sym for the same lib
[15:32:52] <kaduk> You might end up in such a case if you checkout different commits and don't clean up everything in between.
[15:32:57] <deason> so nevermind, that's not any more confusing than what happens with .c files and vpath etc
[15:33:57] <kaduk> Anyway, there's no real reason to not just make the symbol files always generated; we could do that if it seems cleaner.
[15:35:15] <deason> doing that would also avoid needing to 'move' files from static to generated if they ever need to be conditional; it's kind of annoying when that happens
[15:35:32] <kaduk> I also tried using LT_LDLIB_shlib_missing for libafsrpc (I think it was), but then everything that links libafsrpc would also need to use that rule, which seemed silly.
[15:37:20] <kaduk> I will try to remember if there was any other libtool fallout that we should care about before branching.
[15:37:58] <Jeffrey Altman> thanks.
[15:38:11] <Jeffrey Altman> is there anything on master now that should be removed after branching?
[15:38:34] <kaduk> When I was trying to only build pthreaded rxgk libs and not lwp ones, I ran into a lot of trouble with libafsauthent_pic, but the solution to that is to just build lwp rxgk libs and stub out the gss routines for that build.
[15:38:54] <kaduk> There probably are things on master that should be removed after branching.
[15:39:16] <wiesand> [building master as a fake 1.8.0pre0 on EL6]
[15:39:34] <kaduk> I guess we already flipped the disable-kauth-by-default switch on master, and we can't really rip it out entirely, either.
[15:40:13] <kaduk> Do we think the libadmin stuff is actually functional anymore?
[15:41:02] <Jeffrey Altman> it is very out of date but it does function and is required for many of the Windows GUI tools that are used by a variety of sites even if they don't get much love.
[15:41:05] <wiesand> [whatfid doesn't build ;-) ]
[15:41:30] <kaduk> We should probably think about moving some tfoo versions to be just foo.
[15:43:39] <kaduk> There's still a decent amount of stuff in src/util/; it might be too much work to push and kill it entirely.
[15:44:36] <Jeffrey Altman> I don't think src/util can go away entirely
[15:47:05] <kaduk> Anyone else have ideas for things that might be candidates to go away on master post-branch?
[15:47:41] <Jeffrey Altman> go away on the branch post branch
[15:48:01] <Jeffrey Altman> I'm thinking of things like rxgk which are not going to be supported on the branch release.
[15:48:28] <kaduk> Oh, I guess I misunderstood.
[15:48:43] <Jeffrey Altman> post branch.  wouldn't it be nice if lwp disappeared on master ?
[15:48:54] <kaduk> It would :)
[15:48:55] <meffie> yes
[15:49:52] <kaduk> Does windows have something analogous to posix_spawnproc()?  I wonder if we can get rid of procmgmt on master.
[15:50:34] <kaduk> I think we said tbozo should not exist on the 1.8 branch, but it doesn't currently exist anyway.
[15:51:14] <kaduk> I don't think there's very much on master now that should get removed from the 1.8 branch.
[15:51:22] <Jeffrey Altman> nothing like posix_spawnproc()
[15:52:10] <Jeffrey Altman> when Simon is back from the Far East and has network (perhaps early July) we should branch
[15:52:43] <kaduk> Sounds good.
We should probably send mail to continue the brainstorming we were just doing.
[15:53:47] <Jeffrey Altman> could you create a wiki page?
[15:53:57] <kaduk> I think so.
[15:54:07] <Jeffrey Altman> thanks
[15:54:20] <wiesand> Branching soon is good. Fixing things up will be easier than doing it now on a moving target.
[15:56:32] <wiesand> So we branch as soon as Simon is available?
[15:57:27] <wiesand> NB if we'd need a 1_6_8_x branch next week, would we be in trouble?
[15:57:30] <deason> is there something we need simon for?
[15:57:46] <meffie> i assume the gerrit setup?
[15:57:48] <kaduk> Simon understands how gerrit is configured.
[15:59:39] <wiesand> Ok. Anything else to discuss today?
[16:00:53] shadow@gmail.com/barnowlC1E71073 leaves the room
[16:01:08] <wiesand> Thanks a lot everyone!
[16:01:08] shadow@gmail.com/barnowlC1E71073 leaves the room
[16:01:08] shadow@gmail.com/barnowl7628413F leaves the room
[16:01:08] shadow@gmail.com/barnowl7628413F leaves the room
[16:01:08] shadow@gmail.com/barnowlC1E71073 leaves the room
[16:01:08] <meffie> have a good week.
[16:01:41] <wiesand> Now that the heat wave here is over, chances are I will :)
[16:03:10] wiesand leaves the room
[16:04:42] deason leaves the room
[16:06:08] meffie leaves the room
[16:16:32] shadow@gmail.com/barnowl853202E0 joins the room
[17:00:14] Marc Dionne leaves the room
[17:58:12] stephan.wiesand joins the room
[20:07:41] stephan.wiesand leaves the room
[20:15:15] kaduk leaves the room
[21:17:57] Marc Dionne joins the room
[21:18:09] Marc Dionne leaves the room