- Wednesday, July 9, 2014

release-team@conference.openafs.org

Wednesday, July 9, 2014< ^ >

Room Configuration

Room Occupants

GMT+0
[02:01:44] shadow@gmail.com/barnowl853202E0 leaves the room
[02:01:52] shadow@gmail.com/barnowl853202E0 joins the room
[02:03:48] shadow@gmail.com/barnowl853202E0 leaves the room
[02:04:00] shadow@gmail.com/barnowl853202E0 joins the room
[02:22:01] shadow@gmail.com/barnowl853202E0 leaves the room
[02:22:08] shadow@gmail.com/barnowl853202E0 joins the room
[04:51:49] Jeffrey Altman leaves the room
[04:57:03] Jeffrey Altman joins the room
[13:05:03] wiesand joins the room
[13:56:19] kaduk joins the room
[14:00:50] deason joins the room
[14:01:39] <kaduk> mornin'.
[14:01:49] <wiesand> Hi Ben
[14:02:40] <deason> hello
[14:03:08] <wiesand> Hi Andrew. I haven't sent out an invitation or agenda because ~nothing has happened lately.
[14:03:59] <kaduk> It might be worth re-sending the list of changes that need review.
[14:04:06] <kaduk> I guess Simon is not back yet, either?
[14:04:29] <wiesand> No idea.
[14:05:12] <deason> yes, sorry, I should be able to review things between now and the next meeting, but having a list of priority items in front of me would be helpful for that
[14:05:57] <wiesand> hang on...
[14:06:33] <wiesand> http://gerrit.openafs.org/#q,status:open+project:openafs+branch:openafs-stable-1_6_x+topic:stack-reduction,n,z
[14:07:04] <wiesand> And 11308/9.
[14:09:22] <wiesand> I figure that's all we'll get into the next stable release if we want it to be ready when Linux 3.16 is released.
[14:12:35] <wiesand> Terrible weather here. Hot, humid, thunderstorms, torrential rain, but it's not cooling down.
[14:12:42] <deason> hmm, I thought volscan would go in before the stack reduction ones...
[14:13:11] <wiesand> Volscan is a feature, stack reduction is kind of a fix.
[14:14:02] <deason> more people care about volscan, and it's less risky
[14:14:48] <deason> (stack reduction fixes an issue affecting [0,1] sites, as far as I know)
[14:14:56] <deason> (at least, in its current form)
[14:16:04] <deason> but sorry, I don't mean to argue :) it's not really important, we'll see what's ready
[14:16:28] <wiesand> And at the rate we had reviews lately, no chance get volscan merged before we have to issue pre1.
[14:16:30] <shadow@gmail.com/barnowl853202E0> volscan is a feature which carries no risk. if you don't want it,
ignore it
[14:17:10] <wiesand> I want it :-) But noone except Chas reviewd the changes.
[14:17:18] <wiesand> For a month now.
[14:18:46] <deason> have we talked to ken about rhel7 rpmfusion packaging?
[14:18:56] <kaduk> This is kind of the season for people going on vacation, though.
[14:19:00] <deason> or has anything happened there?
[14:19:04] <shadow@gmail.com/barnowl853202E0> perhaps not coincidentally, my life went to hell at the end of may...
[14:19:34] <wiesand> I didn't complain. Just state the facts.
[14:19:59] <wiesand> We'll have volscan in the release after then. Fine.
[14:20:19] <wiesand> Daria, want to share?
[14:21:07] <shadow@gmail.com/barnowl853202E0> well. what i was getting at is my availability has been shit because i
am fighting lots of (personal) fires.
[14:21:25] <wiesand> Sorry to hear that.
[14:22:08] <wiesand> RHEL7 packages would be ELRepo, not rpmfusion.
[14:25:42] <wiesand> Doppler Radar suggests I'll soon have a 10m window between two thunderstorms to get to my car :)
[14:25:47] <deason> did that change since last I was here, or did I mix up which was which?
[14:26:05] <wiesand> No change.
[14:26:21] <wiesand> rpmfusion does Fedora. ELRepo does EL.
[14:27:20] <wiesand> ELRepo packages are unmaintained, and Ken is considering stepping up.
[14:27:27] <kaduk> Go get to your car when you can; we don't seem to be doing anything important here...
[14:28:09] <wiesand> Will do ;-) But the gap isn't quite here yet...
[14:29:18] <deason> "ken is considering" I assume comes from actual communication with ken? like, he is actually aware of all of this?
[14:31:38] <wiesand> Just forwarded two e-mails on this.
[14:32:22] <wiesand> Do they answer your questions?
[14:33:12] <deason> I suppose, but they are a few weeks old
[14:34:26] <wiesand> The common desire seems to be to leave packaging to downstream. Why not simply do exactly that?
[14:35:33] <wiesand> I'll provide packages for SL7 ;-)
[14:35:38] <deason> that is what we're doing, but there's still a kind of hand-off
[14:36:05] <deason> if we just stopped releasing packages, downstream eventually would come up with something, but it'd be fragmented and would take a while
[14:36:38] <deason> blessing a particular downstream source gives people an obvious thing to migrate to; so "we" as the openafs release team, still have a little involvement
[14:37:17] <deason> well, what are you using for sl7 packaging? or are you already using a different specfile etc?
[14:37:43] <deason> I thought sl would just use the same packaging as elrepo or whatnot
[14:38:02] <wiesand> I think we won't bless the ELRepo packages. Not sure I'd bless the SL ones. Everyone wants weak_updates kmods.
[14:38:37] <wiesand> SL is still on transarc paths. Mostly.
[14:38:50] <wiesand> May change with SL7. May not.
[14:39:44] <deason> "everyone wants" meaning the package repos? or users?
[14:40:18] <wiesand> SL maintainers. And I think ELRepo won't admit anything else.
[14:40:32] <deason> because I don't see that happening; we need a way to turn that stuff _off_ but I'm not sure if that's possible
[14:40:46] <wiesand> It isn't.
[14:41:24] <wiesand> In SL6, I defused it a bit by modifying the kmod handling to have a module per minor release.
[14:41:40] <wiesand> Reading the fine print about kABI, this *should* be ok.
[14:43:31] <wiesand> In short, I don't see this going anywhere. Well.
[14:44:32] <deason> er, so there's just a new kmod rpm so it upgrades when people upgrade?
[14:44:54] <wiesand> ?
[14:45:11] <deason> it seems like someone would/could still get stuck with an older openafs client module with a newer kernel that way
[14:45:19] <deason> I was just trying to understand what you did with the kmods
[14:46:10] <wiesand> There's one module for the -371 series (6.4), one for the -431 series (6.5), etc
[14:46:50] <wiesand> Modules are pushed together with the first kernel for a minor release.
[14:47:53] <deason> but that prevents someone from installing the libafs for -371, and upgrading the kernel to -431 with the same libafs?
[14:48:36] <wiesand> the -371 module will not be picked up by the -431 kernel and vice versa
[14:48:54] <wiesand> but both can be installed at the same time
[14:49:07] <wiesand> so you can update the kernel and still restart the afs client
[14:49:22] <wiesand> or boot the old kernel after the update
[14:49:45] <deason> how are you specifying that? such that the -431 kernel doesn't detect the -371 module
[14:50:07] <deason> because that sounds like effectively "disabling weak-updates" to me
[14:50:37] <wiesand> modified openafs specific copy of the scripting
[14:51:40] <deason> but I mean, what about the .ko says not to use it for -431
[14:51:41] <wiesand> it disables weak-updates between kernel series corresponding to different minor SL releases, yes
[14:51:48] <deason> unless you mean you have scripting to remove the symlinks or something?
[14:52:44] <wiesand> yes, it's really just the scripting not making those more questionable symlinks
[14:53:22] <deason> I thought that wasn't under our control, that the kernel packaging or something similar did that
[14:53:34] <deason> it's the kmod-openafs*.rpm packages that normally create those?
[14:54:41] <wiesand> it's up to kmod-openafs what scripts are called in %pots etc.
[14:54:53] <wiesand> ours call /sbin/openafs-modules :-)
[14:55:54] <wiesand> wjhich is a hacked copy of weak-modules
[14:56:11] <deason> okay, so it seems entirely possible to disable the weak-updates stuff then
[14:56:49] <wiesand> Sure.
[14:57:07] <wiesand> If you do the packaging.
[14:57:17] <wiesand> Which we won't.
[14:58:59] <wiesand> Next thunderstorm...
[15:02:35] <wiesand> It seems ATRPMs has dropped openafs too. Good thing for other reasons...
[15:03:59] <wiesand> Ah, they haven't.  Still 1.4.14.1. though ;-)
[15:04:21] <wiesand> And residing in "bleeding" ;-)
[15:04:40] <kaduk> what you will be doing if you are running it?
[15:05:36] <wiesand> I'll use what I contribute to SL.
[15:06:17] <kaduk> ("bleeding", for something that is older than 1.4.15)
[15:06:22] <wiesand> Matter of pride.
[15:07:18] <wiesand> Main package was built 2011-07-02.
[15:07:33] <wiesand> But there's a module for the latest EL6 kernel.
[15:07:49] <wiesand> At least it's not  a weak_updates kmod ;-)
[15:11:38] <wiesand> Ok, here's my gap. I'll run now. Should be back online in ~30m though. Or struck by lightning...
[15:12:11] <kaduk> Don't die.
[15:12:49] <wiesand> That's why I'm preferring the gap over using an umbrella ;-)
[15:12:52] <wiesand> Bye.
[15:13:04] wiesand leaves the room
[15:13:47] meffie joins the room
[15:13:56] <kaduk> Hi Mike.
[15:14:13] <meffie> hello
[15:15:06] <kaduk> Oh look, there was traffic on 6877.  I wonder why I didn't get email about it...
[15:15:46] <kaduk> There goes most of my question for you :)
[15:17:09] <kaduk> Now I have to figure out what other closed change I had commented on (months ago) and see if anything happened there...
[15:19:40] <kaduk> Anyway, do you want to submit a followup patch for that logging issue, or should I throw something together?
[15:21:19] <meffie> i can do it. sorry about that.
[15:21:52] <kaduk> Thanks.  It's not a big deal, I just don't want it to get lost.
[15:33:48] deason leaves the room
[15:33:49] deason joins the room
[15:49:21] stephan.wiesand joins the room
[16:19:11] deason leaves the room
[16:19:11] deason joins the room
[18:09:52] stephan.wiesand leaves the room
[19:53:07] meffie leaves the room
[20:32:04] kaduk leaves the room
[22:30:53] deason leaves the room