[04:05:34] --- wiesand has become available [04:05:53] git tag [04:47:36] --- meffie has become available [06:59:59] --- deason has become available [07:00:17] Hi [07:00:28] hello [07:00:37] good day. [07:01:11] Is anyone else actually here? [07:01:23] I am [07:01:58] I'm not sure which if any of the five shadow@gmail.com that I see are real [07:02:24] Thanks. Looks like this will be a brief meeting. [07:02:50] I see a single shadow only (7628413F) [07:03:17] Let's start. [07:03:44] Since Marc isn't here: I guess noone here tested against Linux -rc5? [07:04:19] Next topic: problem reports. [checking RT now...] [07:04:57] Nothing new in RT it seems. [07:05:10] Andrew: any news on the NBSD fssync problems? [07:05:30] no [07:05:31] --- Marc Dionne has become available [07:05:52] Any news on the multiple mounts issue? [07:05:58] IMO we don't need to be putting that on the agenda; it's not urgent and I have things in front of it [07:06:09] the mounts thing I have a prototype mostly developed [07:06:28] I haven't hit any unsurmountable roadblocks yet [07:06:53] Good news. Any ETA for it hitting gerrit? [07:07:33] maybe sometime next week [07:07:34] I could probably test it a bit, if that helps. [07:08:11] sorry for being a bit late - current linux mainline is fine (rc5+) [07:08:24] Marc: Thanks. [07:08:59] Next topic: Any news on the 1.6.7 security release? [07:09:49] (Jeff, you're likely the only one who has the information?) [07:10:06] or shadow if he becomes "really here" [07:10:40] Well of course, but it looks like he isn't. [07:10:56] So, no news. next topic: 1.6.8 [07:11:30] I merged quite a few changes after last week's meeting, but many still lack review. [07:11:34] I don't believe that there are any code issues. Simon is the one to handle the CVE and other signing issues. [07:12:33] Thanks Jeff. It would be good if we managed to preannounce it this time (as discussed last time). [07:12:56] do we have an ETA for getting that? do we know if he (or anyone) is actually working on it? [07:14:19] I propose I ask Simon via PM. [07:14:49] Back to 1.6.8? [07:16:07] I think I'll merge the vnodeunique rollover ones after the meeting, unless there are objections raised now. [07:16:57] GUACB is probably difficult to get any review for at all. If i were opposed to the feature, I porbably wouldn't do it either ;-) [07:18:36] 10857 seems stalled. Blocks 10757. [07:19:26] Any objections to "interrupt RX calls"? (6266 10799) [07:20:01] I'd like to take a pass at reviewing before merging, but it doesn't need to block on it [07:20:34] Andrew: which one? [07:20:53] "interrupt rx calls" [07:21:19] was there a particular motivation for the new bozo changes? (not objecting, just haven't looked much yet at them) [07:21:58] I was going to ask the same question [07:22:00] I was looking at trvivial changes recently merged on master to pull up. [07:22:24] Found the "remove MR AFS remnants" one. [07:22:42] Didn't apply, so I ventured to find the others. [07:22:45] --- Simon Wilkinson has become available [07:23:30] I'm very much interested in thoughts on whether something like the boz-catchup stack makes sense. [07:23:35] Hi Simon! [07:24:18] hi [07:24:30] Any input regarding 1.6.7? [07:24:53] removing the mr-afs stuff would be nice, yeah [07:25:39] clang and coverity fixes can certainly be pulled up. [07:25:49] Just diff boserver.c between 1.6.x and master berfore and after applying the stack. I think it's worth it. [07:27:23] One of the changes in the stack is not a 100% clean pullup, leaving out something that will never hit 1.6 (I think it was heimdal related). All the others are - if they can all go in. [07:27:59] Jeff, thanks for looking at them. [07:28:43] 1.6.7 is just blocked on me doing the security release dance, which takes time that I don't have right now. [07:29:39] Fine. It would be nice to have some advance notice once you do. [07:30:01] Okay [07:30:03] dead code removal on a stable branch for example is questionable [07:30:05] Do you have objections to a 1.6.8pre1 before 1.6.7 is out? [07:30:15] No [07:30:35] Jeff: it has been dead on the stable branch for a long time too. [07:30:37] can anyone else help? istr last time we had offers from others for going through the process of asking for a cve [07:30:59] --- Derrick Brashear has become available [07:31:11] I'm going to ask the original reporter if they have time to write text for an advisory. [07:31:15] there, finally have a client which will let me send :\ [07:31:23] :) [07:31:26] Once that's written, if others have time to do the CVE dance, that would be great. [07:32:25] I can offer collecting binaries, uploading them, doing the web page etc. if that helps. [07:33:44] If we do this before 1.6.8 (aka "keeping jhutz happy"), then I don't think we need to do binaries. [07:34:18] agree [07:34:33] I don't believe this would keep jhutz happy ;-) [07:34:54] fail to additionally upset jhutz [07:35:03] heh [07:35:27] will debian need to do something? [07:35:30] I figure he'll have a strong preference got 1.6.7 binaries even if we release 1.6.8 the very same day. [07:35:36] e.g. russ? [07:36:02] Debian will need to do something for whatever their stable release is [07:36:31] Will there be a separate patch or easily identifiable git commit? [07:36:37] there will [07:36:48] that's the point of 1.6.7 [07:36:53] There always is. [07:36:59] Will it be hard to backport to 1.4. ? ;-) [07:37:00] And yeah, that's the point of 1.6.7. [07:37:01] the security patch is diff 1.6.6..1.6.7 [07:37:11] there will be a whole separate branch [07:37:18] yes, there will be a patch for 1.4, no release (as I understand it) [07:37:19] Well, the point of 1.6.7 is "people shouldn't have to take all of this new stuff just to get a security fix" [07:37:52] Yeah, 1.4 we provide patches (until some point that we said we'd stop) but no release. [07:38:04] sometime in may [07:38:20] Right, which is why I believe "some" would like to see us release 1.6.7 binaries. [07:39:32] Will I want to scramble and have everything updated an hour after the announcement? [07:41:12] Its not appropriate to answer that question. Certainly not in a public forum [07:42:29] Right, sorry. [07:42:57] which does raise a question of timing. given that we know that many sysadmins will be traveling for EAKC should a security release be held until the following Wednesday [07:43:31] Well, it depends on the answer that can't be given ;-) [07:44:30] We should certainly aim to be ready to go by the end of the conference [07:44:41] I don't think so. some orgs have a policy that all security updates must be evaluated and/or applied within X days [07:44:43] bbiab [07:44:44] Please don't release it on a Friday, preferably not during EAKC or the day before or so, and preferably after a week of preannouncement. [07:45:09] --- Simon Wilkinson has left [07:45:09] That's me as a site admin And I bet many others feel the same way. [07:45:22] "bbiab"? [07:45:27] back in a bit [07:45:29] pre-announce at EAKC [07:45:39] release the wednesday after [07:45:53] Sounds good. [07:47:24] I believe we're through. Anything else to discuss today? [07:47:42] i have nothing [07:48:10] getting back to the subject of dead code. the general objection to removing dead code from a stable release series is that it adds to the quantity of code that must be reviewed by someone that reviews each change before deploying a new release. [07:49:00] I have another thing [07:49:29] I'm not clear on if I'm writing another draft for the mtpt "alert" or whatever, or what format it should be taking [07:49:32] Andrew: ok. But Jeff: who's doing this? And: isn't that the most trivial kind of change to review? [07:50:04] jhutz and chaskiel are certainly two individuals that do that [07:50:33] I know of others but won't mention their names or affiliations in this forum [07:51:06] Removing artificial, unnecessary differences between master and stable makes reviewing real changes much easier IMO. [07:52:09] if the 'dead code' is "if 0"d, which a lot is, then it really doesn't add to review load [07:52:22] if it's code that is actually unreferenced by the tree, buildbot would pick up any errors [07:53:11] in this particular case, I thought they were helpful for pulling up the mr-afs stuff, but I guess I don't know that because I haven't looked at them yet [07:53:46] The MR-AFS stuff is dead code removal. [07:54:22] the mr-afs changes are not dead code. it is code that is not used by anyone. [07:54:36] Right. [07:55:09] that is a big difference [07:57:11] Right again. [07:57:47] removing mr-afs is an unnecessary functional change to the stable release series [07:59:17] It's not expected to cause any problem anywhere. Is it? [07:59:18] the extra options are confusing to users; it displays unusable functionality in -help output [07:59:38] that was the whole motivation for submitting the original change, because I kept getting questions about it [08:00:07] it also makes the help output less readable and less useful, imo [08:00:25] but I also don't see what this conversation is doing here, outside of the relevant gerrits [08:00:46] It's a "stable branch" policy issue. [08:02:00] I understand reservations regarding unnecessary changes in 1.6.x. [08:02:35] I also hear complaints that the skew between master and 1.6 is making work on 1.6 difficult. [08:02:37] it's not something you can make sweeping generalizations about; it's just how much benefit a change has vs how much risk [08:02:44] yeah, basically, it's attempting to establish what consistency guarantee we want to make [08:03:17] if the argument is that mr-afs command options on 1.6 are confusing to end users then a patch that makes them "hidden" would be appropriate for the 1.6 series. Removing them outright which would break command execution in the unlikely chance that there is a reference to one of the options in a script is not. [08:04:30] deprecated before deleting? [08:04:53] I thought they didn't work already [08:05:31] deleting on master is fine. removing command line options in the middle of a release series is undesirable [08:06:10] I wasn't aware of a situation where they "work" now where it would "not work" after that change was made [08:06:24] but if you're saying that's not "guaranteed" or even wrong, then okay [08:06:36] but it still seems competely like a per-gerrit issue [08:07:52] I'm not understanding the point you are trying to make. We are discussing a specific set of gerrit issues and whether they are appropriate for 1.6 [08:08:23] I'm saying there is nothing here that is worth discussing here vs just in the individual gerrits [08:08:49] Jeffrey +1'd all but "remove MR-AFS" and 10864 [08:08:51] the only question is whether the ms-afs-related changes "do" anything, wrt backwards compatibility or user visibility etc [08:09:40] discussing it here is wasting people's time and making it closer-to-impossible to discuss things that can't be discussed elsewhere [08:09:50] in particular I'm objecting to 10864 -> 10866. Stephan asked my opinion and rationale and I offered it. [08:10:04] yes, okay, but I think we can defer any more discussion to those gerrits [08:10:41] er that is, I think further discussion can go _in_ those gerrits [08:10:53] I think discussing it here was appropriate. [08:11:31] I need this kind of input. [08:11:50] okay, but can it stop now? can we move on? [08:11:57] it might be a good idea for wiesand to write up something to put the policy types of issues on wiki.openafs.org, for the future. [08:12:50] lucky him [08:13:00] I don't define the policy. [08:13:24] we'll i mean to capture the general consensus, no? [08:13:36] Andrew would like to bring up another topic. [08:13:40] ok. [08:14:18] so... moving on? [08:14:24] +1 [08:14:36] Fine. But ... [08:14:57] well, I was waiting for wiesand; I consider him driving the meeting [08:14:57] the "mtpt alert" discussion is being held on the list. Or rather stalled. [08:15:12] well yeah, that's the point [08:15:20] I can't get anyone to say anything on the list, so I thought I could try here [08:15:41] Now that's one *I* belive should be discussed there at this point,not here ;-) [08:16:22] because the list is private? or you think it's just more suited to a mailing list...? [08:16:28] or at least in the openafs room [08:16:47] Because not all who participated are here. [08:17:47] we don't need jhutz here just to have people say if they disagree or agree with jhutz [08:17:50] Andrew: in a perfect world, what would be the next thing to happen? [08:18:13] If they disagree with jhutz, they should sure do it in the list thread. [08:18:58] in a perfect world, you or the gatekeepers would decide how you want the alert to be issued and make that clear [08:19:22] if doing what jhutz says with the similar-to-SA-alerts alert style, or just do it kinda informal and ad-hoc as previous ones have kinda been done [08:20:11] having something semi-formal (but not a CVE) would be my preference [08:21:10] Citing my mail: [08:21:13] How about "Bug Advisories" for those cases? Not kept secret, and assigned a "BA" number rather than an "SA" one, but otherwise handled (and formatted) very similarly? [08:21:14] and not an OPENAFS-SA. Its a bad bug. We make informal announcements of bad bugs. I believe that simon replied to you with his security officer hat on [08:21:26] or I suppose I should say, in a perfect world it would be clear who's decision this is to make, and then they can make it and we can proceed [08:21:39] It is Simon's [08:22:05] but it's not a security issue [08:22:18] He made the determination that it was not [08:22:26] (at least, that's what simon says, and I thought there was general agreement on that) [08:23:29] the question is not "is this a security issue?", it's "how are we 'alert'ing people to such a non-security issue" [08:23:36] As such it is a bug. We have in the past made announcements about bad bugs to openafs-announce. Sometimes as part of release announcements that include fixes and rarely as a separate e-mail to advise that an issue is known [08:23:52] yes, that's how we've done them before [08:24:07] jhutz suggested something like what wiesand says above like a "bug alert" [08:24:56] so, on the one hand, I have the way that we've been doing it (although with very few prior cases), or I have the way that one person (jhutz) suggested; I think I happen to agree with jhutz, but mostly I don't really care [08:24:58] If we had a fix at hand, the 1.6.6.1 announcement would be the right place. We haven't. [08:26:01] and what we have discussed for this release is that a note indicating the problem would be sent to -announce and -info with a link on the home page. We do not have a table of bad bugs. It would certainly be useful if there was a table and for someone to go back through all of the announcements to enumerate the list. I do not think it is required. [08:27:15] I assume that means you are also in favor of a more informal announcement, instead of one formatted similarly to a security alert [08:27:38] and actually yeah, something that looks like a security alert may be a bit confusing, since people may think it is a security alert, since until now that's the only thing we announce that looks like that [08:27:58] You can always start a list. It would be something like BA-2014-001 anyway. But frankly, I don't have a strong preference either. [08:28:27] but the thing I _really_ would like to get out of this is who is making this decision [08:28:52] so far everyone just has some kind of not-strong opinions one way or the other, so I don't think a strong feeling of consensus will emerge [08:28:55] It's not a release issue. So: not me. [08:29:44] i am happy to make an executive decision that we do it jhutz's way, [08:29:52] and people can hate me for it, or not. [08:30:05] but, like, i am happy for the buck to stop here [08:30:15] From my perspective as soon as it is not a security issue it becomes a member of the development community deciding to send an informational notice. I don't think that has to come from a gatekeeper [08:30:57] okay, so it's not coming from "the openafs project"? [08:31:14] instead it's coming from me / sna? [08:31:29] if you are sending it, its coming from you [08:32:15] If it's sent through -announce, I consider it coming from the project. [08:32:19] Derrick Brashear: and I didn't mean for it to be a mandate, but like a "what we're doing if nobody objects" [08:32:30] nah, I don't think so, non-openafs-project stuff goes through -announce [08:32:37] lots of stuff goes through announce that doesn't come from a gatekeeper [08:32:51] the "openafs project" just approves or rejects things, that's how I see it [08:33:40] sure, russ sends announcements of his useful to afs user software there [08:33:56] even that assumption is weak because the mailing list maintainers are not necessarily an authority [08:34:04] yup. [08:34:53] okay, that discussion satisfies what I wanted out of that, thanks [08:34:53] --- wiesand has left: Lost connection [08:35:06] if everyone else is satisfied with that, I'm done with that topic for this meeting [08:35:31] I'll send something to release-team in that thread based on this [08:39:10] so... uh, "anything else"? [08:41:00] --- stephan.wiesand@googlemail.com has become available [08:41:31] got kicked out… no clue why [08:42:16] --- wiesand has become available [08:42:40] --- stephan.wiesand@googlemail.com has left [08:43:11] I have nothing else [08:43:24] Ok. Thanks a lot everyone. [08:43:42] Bye. [08:43:43] --- wiesand has left [08:45:21] --- meffie has left [09:05:24] --- Simon Wilkinson has become available [09:14:48] --- Jeffrey Altman has left: Disconnected [09:15:00] --- Jeffrey Altman has become available [09:19:23] --- Simon Wilkinson has left [10:10:25] --- Marc Dionne has left [10:11:20] --- Marc Dionne has become available [10:36:19] --- Simon Wilkinson has become available [11:08:28] --- Simon Wilkinson has left [11:10:00] --- Simon Wilkinson has become available [11:42:12] --- Simon Wilkinson has left [11:42:12] --- Simon Wilkinson has become available [11:42:12] --- Simon Wilkinson has left: Lost connection [12:26:39] --- Derrick Brashear has left [12:30:48] --- Simon Wilkinson has become available [13:01:53] --- Simon Wilkinson has left [15:15:32] --- deason has left [15:25:23] --- Simon Wilkinson has become available [16:18:24] --- Simon Wilkinson has left [23:35:16] --- Simon Wilkinson has become available