[06:25:41] --- meffie has become available [06:48:39] --- wiesand has become available [06:59:45] --- shadow has become available [07:00:16] Hello [07:00:35] 'owdy. [07:00:46] hello [07:01:33] ${timeofdaygreeting} [07:02:19] Let's postpone the problem reports until andrew joins [07:02:33] Let's postpone Linux until Marc joins [07:03:02] Bringing us to item 3) on the agenda. Jeff, are you here? [07:03:13] Just say tomato and call the whole thing off [07:03:42] Tomato. Call off what? [07:03:47] i say tomato [07:04:16] (it is an old song...) [07:04:18] It's a song from a 1950s musical [07:04:26] --- deason has become available [07:04:42] sorry, here, hello [07:05:20] Ok, it's a song. Having a hard time to guess the meaning... [07:05:49] So call off what? The announcements? The features? The meeting? [07:06:25] Realize you are getting married to someone with differences. It was a crack because we were delaying everything [07:06:52] Anyway, it seems Jeff isn't here, so we can postpone that again too. But Andrew is, so we can return to item 1: problem reports. [07:06:58] it was just a joke :) [07:07:09] ha! i get it. [07:07:40] Got it. I believe. [07:08:07] on tracy's netbsd thing; working on it, talking with her [07:08:38] Great. How relevant is this to 1.6.7? [07:08:39] I think it may just be that the readv() is returning a short read which it is allowed to do; no idea why it's just on netbsd through apparently, or how to trigger it [07:09:09] if that's what it is, it's theoretically something that could happen anywhere (unless there is a reason it's not happening anywhere else) [07:09:13] So BSD only. Is it a regression against earlier 1.6.x? [07:09:17] but it's been quite a few years and nobody's ever seen it before so.... [07:09:40] We don't know [07:09:43] I don't think so, but I don't know yet [07:09:47] Unlikely tho [07:10:03] Ok, no blocker for the time being. [07:10:07] yeah [07:10:25] Any news on the linux multiple mounts issue? [07:10:52] no, sorry; I was interrupted by something else with higher urgency here, haven't made much progress [07:11:19] there isn't much noise about it on the lists. Maybe it's not that serious in practice? [07:12:00] It may be one of those "it's persistent if it bites you, but it doesn't bite everyone" things. [07:12:39] I'm not sure how common accessing via multiple mounts is, combined with how common the new RHEL versions are [07:13:04] and you shouldn't see a panic in most scenarios, but I thought you'd see that warning any time you access via multiple mounts [07:13:29] so I'm not sure, I haven't spent enough time with it yet [07:13:40] Wasn't the existence of r/w and r/o paths sufficient to trigger this problem? [07:14:17] well, for anything, it's not the mere existance of them in the tree; the client must access them [07:14:41] it's possible just via rw and ro paths, though, with the volume you're actually hitting being an rw [07:14:48] --- Marc Dionne has become available [07:15:20] Ok. No blocker for the time being either. [07:15:34] Last new report I'm aware of: RT #131804 [07:16:50] Any thoughts on that one? [07:17:21] And while you're probably looking into it: Hi Marc. Any Linux news? [07:17:22] we also have a ticket that's for -stayonline not working for someone in some situation, but it's not mine so I don't really know much about it [07:18:02] Some patch to vos since it was [07:18:06] hi stephan and all - compiled and ran a few tests with current linux mainline this morning - still fine [07:18:11] but -stayonline is a newish feature, so... [07:18:12] merged broke it [07:18:20] Marc: thanks. [07:18:23] Still looking [07:21:25] in the meantime... just to note, it looks like 8840 and 6272 (GUACB) were just rebase, but don't build on a few builders [07:21:53] Yes, the LoopServers thing changed. [07:22:04] I don't mind looking at it, but it would be helpful if someone else could; I assume nothing complex is going on [07:22:14] That's a bit beyond what i should do to the tree. [07:22:45] e77d5cea4a11677fea03abb2eb88717a1b686a94 seems to be what got in the way [07:23:08] --- shadow has left [07:23:43] NB nice example for "trivial" rebases not being all that harmless. [07:25:21] But I can try to fix it up. [07:27:12] I didn't have 'you' in mind when I said that, but okay, thanks [07:28:35] Next item: release timing. Thoughts on having a pre1 ready (shortly) before EAKC? [07:30:03] Taking the silence as a "no". [07:30:06] that sounds possible [07:30:19] hey, I'm thinking :) and looking at a calendar [07:30:23] --- shadow@gmail.com/barnowl7628413F has become available [07:30:31] ~ a month [07:30:31] and i'm having my messages eaten [07:30:42] hi, we can see you again, shadow [07:31:03] Derrick: my client says you left a couple of minutes ago [07:31:30] It seems plausibly doable (pre1 pre-EAKC). How fixed is the desired set of features/etc? [07:31:39] wiesand: the only thing that needs additional time that I want in is the linux-mountpoints thing; a month is enough time for that to probably have "something" or at least more discussion/info [07:32:14] yes, that's a good point, are we "freezing" features/bigger changes at pre1? [07:32:28] or before, or nowish? [07:32:33] fwiw there will be a security patch so probably 1.6.7 will be 1.6.8 :\ [07:33:23] anything talking about that should be for the list, I believe, not here [07:33:26] If we go for a pre1 before EAKC, anything major that should go in should be discussed and agreed in principle today. [07:33:40] sure. nothing beyond the fact that it exists :\ [07:34:29] Oh great :-/ [07:34:46] is linux mountpoints still acceptable to be going in? (if we have a fix and more info and etc etc) [07:34:59] But we have merged quite a few changes onto 1_6_x already. [07:35:06] i think it would be a good idea. [07:35:11] Are we ging to revert them all? [07:35:29] for a security release, no, I assumed just a new branch for it [07:35:31] deason: i would think that would depend on how complex the solution is [07:35:38] no. we will branch the previous release, apply the security patch, and then also apply it on the current head of 1.6 [07:35:50] Also on master, please? :) [07:36:01] Ok. But that wouldn't make 1.6.7 1.6.8. [07:36:02] yes, I'm not asking for it (linux mtpt) to be guaranteed to be "in", just that it's not guaranteed to be "out" yet [07:36:21] it would. the thing called 1.6.7 would be 1.6.6.x plus only the security patch [07:36:37] and 1.6.7prewhatever would be released as 1.6.8 [07:36:53] unless we just start calling them 1.6.8pre* [07:37:06] good idea [07:38:03] Hm, cutting 1.6.7 from the 1_6_6_x branch? Messy... [07:38:42] not really. you apply two patches. one that is the security patch. one that increments the version. all done. [07:38:57] we've done it before. it's "solved problem" [07:39:35] just make sure the patch is applied to all relevant branches. [07:39:55] Why not simply have 1.6.6.1 as the security release, and go on with 1.6.7 as usual? (including the security patch, once public) [07:40:13] because, micro-versions (.1) historically have just been platform support [07:40:19] we've not traditionaly done it that way [07:40:22] you are not supposed to "need" them [07:40:41] I thought we had this same discussion during 1.6.5 [07:40:57] Ah, I recall the "micro versions don't work on all platforms" argument. [07:41:09] So, well... [07:41:38] ETA for the security patch? [07:41:48] assume it exists when you are ready to release [07:43:13] OK. I propose we start talking of 1.6.8 rather than 1.6.7, including prereleases, and saying 1.6.7 is reserved for a security-only release. [07:43:37] sounds reasonable [07:43:39] it's a nice round number. [07:44:02] no, 0.0.0 is a nice round number. every digit is individually round. [07:44:21] Mike: 1.6.7 or 1.6.8 ? ;-) [07:45:02] Anyway, this seems agreed. [07:45:14] 1.6.8 (1.6.7 is pointy) [07:45:30] Ah. Ok. [07:45:40] So, back to the 1.6.8 release timing. [07:45:47] Pre1 before EAKC. [07:46:02] mountpoint-thing still to be considered. [07:46:37] Any other major thing we may want to include? [07:47:08] If it's not brought up today, it's for 1.6.9. [07:47:40] I don't think I have anything, but advance notice on knowing that "today is the day" to bring up such things would be nice.... [07:47:54] i'd like a pony. i think we can have it ready for 1.6.8 [07:48:14] It was stated quite clearly in the agenda I sent out yesterday, I believe. [07:48:40] Pony's declined. Posponed to 1.6.9. [07:49:34] bah [07:50:24] shadow, is 131578 still an issue? [07:50:30] oh, it was, sorry; I thought that section had nothing new from the header before it :) [07:50:39] is that a afs-commander crash? [07:53:03] ... looking [07:53:51] yeah, the afs commander things have not been touched. it needs to be revisted with a heavy hand toward use of SMJobBless and probably a better way to manage the CellServDB [07:54:40] ok, that can be discussed on the darwin list? [07:55:02] yup [07:55:24] It's a year old. Hardly a reason to block 1.6.8. [07:56:21] i guess it's keeping people from using afs on macos? [07:56:22] agree [07:56:32] but we dont need to block. [07:56:56] open Terminal.app, create mount point. your definition of "prevent" is unfamiliar to me [07:57:26] yeah, i know i know. the "open Terminal.app" is the "bug" [07:57:29] Terminal.app, that's in the Applications/Utilities folder. Sounds scary. [07:57:43] I think some people would be blocked at "open terminal", but I don't know if those people would be creating mountpoints [07:57:56] i don't know if they should be. [07:58:07] but yes, we should fix it, and no, it's not a blocker [07:58:08] that's a good point actually. [07:58:49] We can do 1.6.8.1 for OS X if a solution becomes ready soon after the 1.6.8 release and it's considered important. [07:59:25] Last item on the agenda: make progress merging. [07:59:44] We really need more review on many changes open on 1_6_x. [07:59:56] I managed to merge two today. [08:00:26] Everything else that would have sufficient review to merge has a dependency on something that hasn't. [08:00:45] I assume you want people to focus on the non -2'd things [08:01:11] For the time being, yes. [08:01:40] Because none of those can be merged without rebasing something. [08:03:01] 10809 seems ready and simple, but it's 1.6-only. I'd really prefer having a gatekeeper's +1 on it. [08:04:29] BTW, in a few cases I'm not quite sure whether changes actually depend on each other. But they're marked like this in gerrit and not sufficiently trivial for me to decide. [08:05:11] So it would really be helpful if changes are pulled up such that they are marked depending on each other if and only if they actually do. [08:05:19] well, I don't necessarily know, either [08:05:28] I pushed all of my changes in a single line because I thought that would be easier [08:05:40] if they need to be rebased, rebase all of them as a single monolithic chunk [08:06:00] For things like supporting a new buildslave configuration, the changes won't depend on each other, but will want to be tagged with a common tag. [08:06:00] (that is, I don't necessarily know either, even for the ones I pushed) [08:06:55] The tag (or "topic") is fine and very useful. [08:07:58] Dependencies are useful too, if used properly. [08:08:44] But putting the same tag on a bunch of commits without making them have spurious dependencies on each other is a pain. [08:09:52] You can repeatedly push a stack of changes to the same topic. [08:10:30] Yes. [08:11:11] I believe that if I push a commit to gerrit that has a parent commit also in gerrit, that parent commit will be marked in gerrit as a dependency of the commit that I am pushing. [08:12:00] I believe gerrit will only mark dependencies between all changes in a stack you push at once. [08:12:20] no, the "dependency" is just what the parent commit of the pushed commit is [08:12:50] it's just another way of saying "the parent commit" or "the child commit" [08:14:48] I think I still don't sufficiently understand gerrit's inner workings. [08:15:24] How can the parent commit be both in gerrit and on my local tpoic branch from which I push? [08:15:31] the "dependency" thing is more of a git thing; gerrit is just telling you about it in the interface [08:15:35] gerrit just tracks ephemeral branches in git for you [08:15:50] I don't understand that question [08:15:56] if the parent sha1 exists in your tree and you push it to gerrit it's still the same sha1 [08:16:20] it is not magic. you're just copying blobs around. the blob does not change when you copy it [08:17:03] The sha1 is the result of the full commit history on the branch. [08:17:26] yeah [08:17:51] ...which implies that gerrit has the whole history and everything; anywhere that sha1 exists, it has the contents of that commit and all prior commits [08:17:55] right. and the whole branch you have is also in gerrit [08:18:30] I'm supposed to create a topic branch off the current HEAD, commit changes, then push. [08:18:46] at some point, everything starts from the root, openafs 1.0 commit. when you push something, either it's already merged, or you push your whole stack between what's merged and what you push. all sha1s exists in gerrit that matter for this commit from your tree. so it's the same [08:20:08] Still not getting it. Will have to do homework. [08:21:16] i saw a good git explainer recently. i will see if i can find it. just realize, topic branch or no, any stack of patches you push to gerrit is just a branch, and then read about git [08:21:16] git takes time to learn, but there are lots of good info these days. [08:22:51] Anyway, the point that I was going to make but stopped when we got confused, was that I could make a bunch of pushes to end up with commits tagged the same that don't "depend on" each other, but then I would not end up with any single branch that could actually build on the new configuration. [08:23:05] oh, one more commit. is there any chance for 9020 to be merged? [08:23:22] (or is there a better way i should try?) [08:24:34] I can look at it today to probably +1 it (that's not an answer, but if it helps...) [08:24:54] ok, thank you. [08:25:26] That probably doesn't count as a major feature, though. [08:26:14] it's just another straw on my back :) [08:26:14] --- Marc Dionne has left [08:26:19] Well, it's another feature in an area where we seem to have a bug.. [08:26:28] sorry for being late. I have been working on the security issue that was brought up earlier. [08:26:29] --- Marc has become available [08:27:28] --- Marc Dionne has become available [08:27:36] mike: I haven't looked at 9020 in a long time. The last blocking comment was from andrew. It is unlikely I will look at it again until after Andrew says he is ok with it. [08:27:40] Thank you for doing so! [08:30:13] Jeff, now you're here: About announcing the "give up callbacks" in advance: It was your proposal. Do you want to do it? [08:30:25] I will take care of it [08:30:45] no point anyone else taking the heat [08:30:59] Thanks. Should we include the changed ih_sync default behavior? [08:31:09] might as well. [08:31:22] Thanks again. [08:32:15] Anything else to discuss today? [08:32:49] don't think so [08:33:32] Ok. Summary: [08:33:40] 1.6.8pre1 before EAKC. [08:33:55] "Feature freeze" now. [08:34:23] mount point thing to be considered for pre1 if ready [08:35:07] and 9020, if there's consensus and it's ready [08:35:41] Anything else should be simple or urgent. [08:35:42] possibly something for nbsd fssync thing? (if it needs something) [08:36:44] If it fixes a serious bug for production systems, it's urgent. [08:37:49] And I think that's it for today? [08:38:22] Thanks a lot everyone. [08:38:28] Bye. [08:38:33] --- wiesand has left [08:38:45] --- deason has left [08:40:43] --- Marc has left [08:42:40] --- meffie has left [10:14:20] --- deason has become available [10:46:52] --- shadow@gmail.com/barnowl7628413F has left [10:51:21] --- shadow@gmail.com/barnowl7628413F has become available [14:12:04] --- Marc Dionne has left [18:22:56] --- deason has left