[05:23:12] --- meffie has become available [06:09:31] --- meffie has left [06:15:24] --- meffie has become available [06:51:40] --- wiesand has become available [07:01:22] Hi Derrick. My client shows you as the only other one present? [07:01:36] That's silly. [07:02:17] Hi Ben, that was my hope. Trying a restart... [07:02:23] --- wiesand has left [07:02:27] --- wiesand has become available [07:02:57] Much better. Now it shows Jeff, Ben, Mike and Derrick. [07:03:18] morning [07:04:31] Hi Mike. [07:04:52] Ok, the plan is to release 1.6.6 early next week. Agreed? [07:05:56] This will be a short meeting, I guess :) [07:06:10] agreed [07:07:11] Any news or other development we'd want to take into account for 1.6.6, besides the spec changes and server side NAT pings? [07:07:29] (and obviously a final test with Linux 3.13) [07:07:33] Is anyone planning to supply Mavericks binaries? [07:07:57] We haven't had much luck with any OS X binaries lately... [07:09:48] I believe building binaries is the easier part. Creating an installer seems special. [07:10:00] Right, that. :) [07:10:45] So, probably not, or not anytime soon. [07:10:46] I got the impression from IRC and such that the tooling in the tree uses an old tool to produce the installer, which is not really available anymore from official channels. [07:10:53] --- deason has become available [07:11:02] that is correct [07:11:24] Apple moved to a new packaging format which is compatible with the AppStore. [07:12:10] Can OpenAFS be distributed through AppStore? [07:12:14] no [07:12:27] Why did I know that :-( [07:12:37] kernel extensions cannot be included in the AppStore [07:13:16] The YFS for iOS has no kext? [07:13:33] Correct [07:14:04] However, that is a different installer and product. I'm referring to the OSX AppStore [07:14:23] Ok. Just curious. Back on topic. [07:14:40] I guess Linux binaries will come from the usual sources. [07:14:58] Anyone else here who's planning to provide anything? [07:15:09] I expect to have freebsd binaries available. [07:15:17] Good. ETA? [07:16:22] Just asking because getting the web changes done and applied is a bit of a hassle. [07:16:48] It might not be until after the release, I have a commitment this weekend that could potentially consume unbounded time. [07:16:58] btw, shadow will be late this morning. He had an urgent pet related issue to address. [07:17:03] we can provide solaris [07:17:40] Andrew: fine. [07:18:24] Ben: If we had tarballs, say, tomorrow that are very likely to be final, would this help? [07:19:09] I'm really not trying to press for anything, mind you. [07:19:35] I don't think it would make a particular difference; the time-consuming part is usually just pulling up new chroots for the latest freebsd releases. [07:20:11] Ok, thanks. [07:21:00] But in general, how about creating tarballs as soon as we have merged the spec changes, "make 1.6.6" and a NEWS update? [07:21:18] sounds like a plan [07:21:43] > pulling up new chroots I will try to get some of that done this week, but we'll see what happens. [07:22:20] And yeah, sounds like a plan. [07:22:26] So I'll do that. [07:22:34] ok [07:23:05] The spec changes have no +1s yet. I feel I shouldn't wait for those longer than til tomorrow... [07:23:42] And merge them after a few test builds on what I have here (EL5/6, F18, EL7 beta). [07:25:05] I see no further obstacles. Shipping unit files on EL7 can wait until 1.6.7 it seems. [07:26:19] the spec files are pullups from master. you should feel comfortable approving them without additional review. [07:26:53] Thanks. [07:27:24] you might as well include the doc fixes [07:27:29] I don't think they need a lot of review, but not because they're pullups from master [07:27:43] being a pullup from master doesn't qualify a change for being included without review [07:28:10] Well, I didn't say I'd apply them blindly. [07:28:30] I tend to look closely at least at changes I can understand ;-) [07:28:38] my point is, they were already reviewed on master. if there are no changes, then the reviews on master apply. the release manager has the ability to use his/her judgement. [07:29:15] And these ones don't touch code. [07:30:15] And of course: even in such cases I wouldn't merge anything before a -1 is sorted out. [07:30:16] it's up to stephan, but I think it makes more sense that "trivial" changes should make it easier to get +1s on the change, instead of just bypassing any +1'ing requirements [07:30:45] sorry, back [07:30:57] The point is that waiting for +1s can easily delay things a further week. [07:31:12] That's often worth it. Sometimes it isn't. [07:31:15] it shouldn't, if it's an easy change [07:31:31] Well, they spent 3 days on 1.6.x... [07:31:36] it's possible to yell at people enough to get that to not be a problem [07:31:39] link the changes here [07:33:12] http://gerrit.openafs.org/#change,10703 http://gerrit.openafs.org/#change,10703 http://gerrit.openafs.org/#change,10703 http://gerrit.openafs.org/#change,10703 [07:33:25] there, now it takes like 2 seconds for anyone here to +1 them if they're okay with them going in [07:33:53] but I really meant it before when I said it's up to you [07:33:57] that's just my opinion [07:34:01] yu feel really strongly about 10703 eh? [07:34:36] (and a link here doesn't help me at all, barnowl in an xterm ;) [07:34:40] It just avoids a pointless deviation from master. [07:35:57] oh, damn copying/pasting on os x [07:36:28] I asked for them being pulled up together because otherwise one of the others is a different change on master than on 1.6.x. Why not avoid if it's that cheap. [07:36:41] http://gerrit.openafs.org/#change,10703 http://gerrit.openafs.org/#change,10619 http://gerrit.openafs.org/#change,10622 http://gerrit.openafs.org/#change,10704 [07:36:44] that's what I meant to do earlier [07:36:48] better ;-) [07:37:04] shadow's comment was in response to deason pasting the same link four times. not because of the content of 10703 [07:37:15] yes. i was being a smartass. sorry [07:37:21] nah nah, I got it [07:37:29] ah, got it. [07:37:34] > smartass I thought that came with the package... [07:37:39] but any way, they have some +1s now so hooray [07:38:35] Thanks. [07:38:54] The last open question is that about the server side NAT pings. Votes? [07:39:30] (or better: news?) [07:40:29] no news; we agreed to take it out on no news so I assumed it was getting taken out [07:41:58] If noone has a preference to rip them out, I'll leave them in. [07:42:11] I can re-push the reverting change, if someone wants to -1 or +1 it [07:42:23] it's extra traffic, imo, so nominally i would prefer out. but not particularly storngly [07:43:06] As for almost everything else, we'll get useful feedback *after* releasing. [07:43:12] If at all. [07:45:57] I would prefer it be removed as agreed since there has been no evidence presented that there is improved behavior to justify the extra network traffic. [07:46:49] Ok, that's 2:0 for removal. Andrew, could you update the reverting change? [07:47:00] I think that the arguments for removal outweigh the arguments for keeping it in. (Neither are very strong, but still.) [07:47:25] 3:0 - fine :) [07:48:04] It's one of those decisions that are hard without expert input. Personally, I don't care for the client dies pings either... [07:49:14] So let's revert this. Smoke testing should suffice for justifying this one without a pre3, because it's so simple. Right? [07:50:34] there is a version of server side pings that I could support. If the file server detects the same UUID bouncing among multiple ports on the same IP address, then it activates the server side version packets until such time as one of the following is true: (a) the UUID is detected on a new IP address; (b) the client has no outstanding callbacks. [07:51:21] 10712; it still has to go through master first [07:51:29] er, that is, http://gerrit.openafs.org/#change,10712 [07:52:16] technically we could revert it only on 1.6 and decide what master will ultimately do [07:52:20] It wasn't quite clear to me that this had to go through master. [07:52:21] deason, for now I would say just revert the 1-6 pullup [07:52:25] e.g. un-pullup [07:52:38] so without further action it still stays on 1.10+? that seems odd to me [07:52:52] I thought I had the 1.6-only change just as a reminder to do it 'properly' [07:53:35] master is not 1.10+. There is no 1.10+ until a 1.9 branch is cut and when that happens we can revert things that do not belong there if necessary. [07:54:12] We've done that with another change in 1.6.6. Revert (=undo the pullup) on 1.6.x, while an improvement is being worked on on master. [07:54:16] we've carried changes on master til the next branch point before, and then patched them out [07:54:46] well, there is no improvement being worked on [07:55:05] Jeff just proposed one ;-) [07:55:44] the way that was phrased didn't make me think he was going to implement it [07:56:19] and unless I hear back from the person that wanted to try this out, there is no motivator for it; nobody is asking for this stuff to be done at all [07:57:03] if there is no customer with a real world problem, why did you do this? [07:57:17] Then revert it on master too. I fail to see why 1.6.6 has to wait for that. [07:57:26] agreed [07:58:07] just to confirm. YFSI will not be implementing my proposal. [07:59:01] Andrew: Thanks for the updated 10135. [07:59:07] "please review" [07:59:12] because I see filelog messages all the time with obviously-natted addresses that are unreachable; but the relevant people don't really care enough to do much about it [08:00:30] so I submitted a change that took a very small amount of time that I thought would help people; one of those things where I thought I would just try, but I wasn't going to spend a lot of time on it [08:02:23] there is no reason for a do not submit on 10135. It is not blocked on master. It is reverting a 1.6 commit [08:03:10] It was there since August, when Andrew submitted it as a reminder. [08:03:24] gerrit seems to retain -2 scores across submissions [08:03:40] we don't want the cherry-picked message for the master commit, though? [08:04:59] or because the submission has the same patch-id (I assume it does, anyway); well, whichever [08:05:50] the commit messages should be different as they are since they revert different commits. [08:06:30] Yes, seems fine to me. [08:08:24] Ok. I'll write minutes today, and set aside some time tomorrow for finishing up 1.6.6 after smoke testing. [08:08:28] It sounds like we're winding down? [08:08:50] Yes. Unless there's anything else? [08:10:06] It seems not. Thanks a lot everyone. [08:10:44] thanks [08:10:51] Bye. [08:10:53] --- wiesand has left [08:17:14] --- deason has left [10:49:37] --- meffie has left