[06:17:16] --- ktdreyer has become available
[06:37:22] --- shadow@gmail.com/barnowlECEA8F00 has left
[06:37:48] --- shadow@gmail.com/barnowl24CEFB49 has become available
[06:48:59] --- Marc Dionne has become available
[06:58:47] --- wiesand has become available
[07:00:20] <ktdreyer> hi all. I'm actually here
[07:00:35] <wiesand> Hi
[07:00:46] <kaduk@jabber.openafs.org/barnowl> 'mornin'.
[07:01:03] --- deason has become available
[07:01:09] <ktdreyer> :)
[07:01:18] * ktdreyer yawns
[07:01:21] <deason> hi
[07:02:08] <wiesand> The EL5 build in Edinburgh tripped over the infamous "no buffer space available" :-(
[07:02:59] <wiesand> We should revisit 8464 for 1.6.7.
[07:03:08] <ktdreyer> I'm working on getting 1.6.6 final into RPM Fusion todya
[07:03:12] <ktdreyer> today, even
[07:03:39] <wiesand> Great.
[07:04:24] <wiesand> Ben, any ETA for the FBSD binaries?
[07:04:26] <kaduk@jabber.openafs.org/barnowl> I think I will need to make a site visit to my freebsd builder to do
some maintenance; I can probably provide a couple of packages before
that, but you probably shouldn't wait for me.
[07:04:33] <wiesand> (Not trying to press, really)
[07:05:31] <kaduk@jabber.openafs.org/barnowl> (Basically, in order to build for the newest releases, I need to be
running a newer release on the jail host.)
[07:06:05] <wiesand> I'm inclined to wait until Friday afternoon (my time) and then announce with what we have. Any opinions?
[07:06:20] <kaduk@jabber.openafs.org/barnowl> That's fine by my schedule.
[07:06:24] <ktdreyer> works for me
[07:06:30] <deason> I can implement 8464 probably pretty quickly, I can try to get something before the next meeting
[07:06:37] <deason> and yes, that sounds fine
[07:07:01] <wiesand> Ok, thanks all.
[07:07:24] <wiesand> Andrew: "implement 8464" means reverting that server-meltdown-avoidance ?
[07:08:09] <deason> no, we had discussed in that gerrit fixing idle-dead so that the non-idling side is the one that kills the call with the idle-dead timeout
[07:09:10] <deason> right now if e.g. the fileserver takes a long time to process a call, the fileserver says "this call hasn't made progress in too long, so let's kill it" but it is the client that should make that determination
[07:09:26] <deason> and conversely for the client taking too long and the fileserver should kill it
[07:10:21] <wiesand> If it just doesn't reintroduce the 4k holes on busy fileservers...
[07:10:35] <deason> I would just wait until next week; it's easier to discuss a patch that actually exists :)
[07:10:46] <wiesand> Ok, thanks.
[07:11:56] <wiesand> Last item on the agenda: what else should go into 1.6.7?
[07:12:34] <kaduk@jabber.openafs.org/barnowl> Well, I dumped a pile of tweaks that should let the os x 10.9 builder
build the branch cleanly into gerrit.
[07:13:09] <kaduk@jabber.openafs.org/barnowl> There were a couple of patches that didn't cherry-pick cleanly to 1.6,
and got custom commits targetted at the 1.6 branch.
[07:13:12] <deason> there's a bunch of stuff I/we(sna) need to go through and submit; I don't have a list right now
[07:14:17] <wiesand> Getting the os x builder going is a good thing. I haven't looked at how intrusive the changes are. Reviews welcome :-)
[07:14:35] <kaduk@jabber.openafs.org/barnowl> 10746 and 10731 were entirely redone for 1.6; 10735 needed a few more
places changed since we use krb5 for rxkad-k5 on 1.6 (but use
liboafs_rfc3961 on master).
[07:16:37] <deason> oh, also, just mentioning, it would be nice if we had a kind of more explicit cutoff point for "new stuff" into the next release
[07:16:51] <wiesand> In general, I'd like to start merging rather sooner than later, to avoid a long backlog like we had for 1.6.6.
[07:16:52] <deason> I feel like there's a point where we say "nothing new unless it's really important" but when that happens is kind of... gradual, or hand-wavy
[07:16:52] <kaduk@jabber.openafs.org/barnowl> Hmm, maybe I should have reset the author on 10731.
[07:17:25] <deason> wiesand: ACK
[07:18:09] <wiesand> To make that possible: Are the gatekeepers ok with a 1_6_6_x branch, should we need 1.6.6.x releases?
[07:18:31] <shadow@gmail.com/barnowl24CEFB49> sorry, i am here now
[07:18:35] <ktdreyer> what sort of things would go onto 1_6_6_x ?
[07:18:51] <wiesand> Just what went into 1_6_5_x.
[07:20:18] <kaduk@jabber.openafs.org/barnowl> (build fixes and other support for new OS versions.)
[07:21:34] <wiesand> Fixes for actual common problems warranting a . release. Possibly really simple changes that are related.
[07:22:33] <ktdreyer> I don't have a problem with that. Jeff or Derrick?
[07:22:57] <wiesand> Andrew: regarding a cutoff date, I'm having a hard time imagining setting a hard deadline - as for anything else.
[07:23:05] <shadow@gmail.com/barnowl24CEFB49> that in theory is the rule we applied, though we applied common sense.
[07:23:32] <deason> I don't mean setting it in advance, just saying about when it happens
[07:23:49] <deason> or when it's "coming really soon"
[07:25:02] <wiesand> I think that should generally be "when what we have os worth releasing".
[07:26:17] <wiesand> Before that, no point in setting deadlines.
[07:26:55] <wiesand> But after this point is reached, delaying for things not even discussed before makes little sense.
[07:27:44] <deason> it would just be nice to be able to say something like "if you have something you want in that hasn't been brought up, do it in the next week or you'll miss this release"
[07:28:00] <wiesand> We depend on a handful of volunteers for everything, thus it's really hard to predict when this point is reached.
[07:28:04] <deason> or something like that; just to give others a chance to get stuff in if they hadn't done it yet
[07:28:11] <deason> but it's just a suggestion
[07:28:19] <wiesand> But yes, I'll try to communicate more clearly when I feel this point coming.
[07:29:01] <wiesand> Point taken.
[07:29:52] <wiesand> Ken: If you want 10631 rewritten, I can do it.
[07:30:17] <wiesand> That's one I'd like to see in 1.6.7.
[07:31:32] <ktdreyer> looking
[07:31:58] <ktdreyer> honestly I'd rather we use a single boolean there
[07:32:31] <wiesand> I can do it with one or no boolean :-)
[07:32:47] <ktdreyer> none?
[07:33:16] <wiesand> Using %if ... || ... logic.
[07:33:45] <ktdreyer> like solely use dist tags on all the conditionals, and not use a "systemd" boolean at all?
[07:33:54] <wiesand> Both cases just require shuffling around some if/else blocks rather than replacing the %ids one by one.
[07:34:02] <wiesand> Right.
[07:35:29] <ktdreyer> here's what I'm using in RPM Fusion:

%if 0%{?rhel} >= 7
  %global _with_systemd 1
%endif

[07:35:48] <ktdreyer> and I think Jack was using the same in ELRepo
[07:35:51] <wiesand> Yeah, but you're not dealing with fedora in the same spec.
[07:35:55] <ktdreyer> I am
[07:36:02] <ktdreyer> Fedora 18 is EOL
[07:36:48] <wiesand> Tell Stephen ;-) He always builds for EOLed Fedoras for a while.
[07:37:00] <ktdreyer> sure, I will tell him :)
[07:37:15] <ktdreyer> I don't think we're doing OpenAFS a service to carry code for old OS releases that the OS vendors themselves haven't supported for years
[07:37:27] <deason> does that matter? I thought the issue was just which variable to use
[07:37:57] <deason> _with_systemd for rhel>=7 or fedora>=5 seems fine, right?
[07:38:04] <ktdreyer> that's fine with me
[07:38:06] <deason> er, fedora>=15
[07:38:34] <wiesand> But some tests are fedora <= something.
[07:39:02] <wiesand> So no simple or. Must reverse tests and shuffle blocks around.
[07:39:10] <ktdreyer> in 10631 ?
[07:39:45] <wiesand> No deal, just a more complicated change.
[07:39:51] <wiesand> Yes, 10361.
[07:40:40] <ktdreyer> I'm not sure blocks need to be shuffled around
[07:41:32] <wiesand> I believe not shuffling blocks around requires two booleans ;-)
[07:41:44] <deason> if it's anything besides fedora 15, then it seems like it's not related to sysvinit/systemd
[07:42:35] <ktdreyer> you can use "!" to negate conditionals
[07:44:28] <wiesand> Yes, but you end up with logic I consider much uglier than two booleans.
[07:44:44] <wiesand> Are parens allowed?
[07:44:47] <ktdreyer> yes
[07:45:18] <wiesand> Even for the ancient rpm in EL5?
[07:45:56] <ktdreyer> I'm pretty sure it was EL4 where they're not allowed. I can check in a moment
[07:46:30] <ktdreyer> yeah, EL4
[07:47:22] <wiesand> Ok, I'll use ( .... || ! ...) etc. Let's see what it looks like.
[07:48:00] <wiesand> And yes, there was one test we should separate.
[07:48:18] <wiesand> (possibly unrelated to systemd/init)
[07:48:37] <wiesand> But we're boring at least a few here....
[07:49:14] <wiesand> So for next week, please prepare a list of topics planned to be addressed in 1.6.7.
[07:49:31] <wiesand> This doesn't mean the changes must be ready yet.
[07:50:20] <wiesand> Anything else we should discuss today?
[07:50:58] <ktdreyer> thanks for being flexible on 10361. I feel bad making you do extra work
[07:51:30] <wiesand> You're the gatekeeper, I want the change ;-) Seriously though: no problem.
[07:51:38] <ktdreyer> good deal
[07:51:54] <ktdreyer> The OpenAFS RPM spec is such a crufty mess
[07:52:08] <ktdreyer> maybe we can re-arrange the blocks in a second commit for cleanliness
[07:52:39] <wiesand> Yes.
[07:54:49] <wiesand> I guess we're done for today. Thanks a lot everyone!
[07:56:23] <ktdreyer> thanks for leading the meeting
[07:56:40] --- meffie has become available
[07:57:16] <wiesand> Hello Mike. Last chance to bring up anything ;-)
[07:58:07] <meffie> sorry, network is wonky today :(
[07:58:15] <meffie> (reading scrollback)
[08:00:01] <meffie> i have nothing to add.
[08:00:29] <wiesand> Fine. Goodbye.
[08:00:32] --- wiesand has left
[08:02:04] --- deason has left
[08:11:44] --- meffie has left
[08:36:37] --- deason has become available
[08:52:42] --- ktdreyer has left
[11:48:35] --- Marc Dionne has left
[15:58:32] --- deason has left