[02:01:20] --- wiesand has become available [05:17:55] --- meffie has become available [05:18:11] good morning. [05:18:45] Good Afternoon. [06:50:58] --- Marc Dionne has become available [06:58:26] --- Daria has become available [06:58:39] good evening? [06:58:59] Daria: how was the sour beer? [06:59:04] Still afternoon. Hi Daria. [06:59:17] Howdy. [06:59:37] Right, Belgium... [07:00:11] no, i am home ;) [07:00:44] not just sour, i also had trappist beers. all was well. i even managed to not get stranded in oostende in spite of my best efforts. [07:00:48] Ah ;-) Fine, let's start. Hi All. [07:00:55] Good work :) [07:01:32] Marc, any surprises in Linux 3.14 final? [07:01:44] nope, everything looks ok [07:01:59] and current mainline is still ok, although it's early in the merge window [07:02:16] --- deason has become available [07:02:20] Good. Thanks. [07:02:56] Chances are, when we get close to releasing 1.6.8 the worst part of merging for 3.15 should have happened... [07:03:15] Next topic: problem reports. [07:03:36] I think a few of you were looking at those stack overflows... [07:03:52] in theory the merge window is 2 weeks, after that there should only be bug fixes [07:03:55] Chas pushed a patch or two to gerrit (for master) [07:04:14] Saw them. Is this a regression? Frequent? [07:04:49] yep. [07:05:03] Both? :-( [07:05:06] Mike: yes frequent or yes regression? [07:06:49] [assuming Mike is typing] [07:06:52] i dont think a regression. [07:07:21] --- meffie has left [07:07:23] Is saving a few bytes of stack here and there going to be the solution? [07:07:50] Probably. [07:08:04] 160 isn't a few when you have 4096 tops to play with [07:08:29] True. [07:08:37] --- meffie has become available [07:08:46] it's almost 4% [07:08:59] --- shadow@gmail.com/barnowl7628413F has left [07:09:06] (the network at cern was better than what i normally have ;) [07:09:13] --- shadow@gmail.com/barnowl7628413F has become available [07:09:25] It better be ;-) [07:10:05] I take it there's not more to say about the stack overflows right now? Do we consider this a blocker for 1.6.8? [07:10:15] i have a fiber terminator box 5 feet from my bed, and the latency to everything i use is lower from this side of the atlantic ;) [07:10:28] yeah, so i dont think this is a regression. just hitting this now because newer ext3 is just going over the stack by 100 bytes. [07:10:37] i don't think stack is a blocker but it'd be good to address if we felt confident [07:11:27] Ok. [07:11:44] Next topic: 1.6.7. [07:12:09] It seems after my whining last week I'll be a bit more involved in 1.6 security releases. [07:12:27] yay! [07:12:31] good [07:12:52] For example, I know we have a CVE. Which also means the clock is ticking. [07:13:45] But details remain to be clarified. [07:13:47] i'll find out from simon what his status is. worst case scenario i have all the material needed and have done this before, since we didn't always have a security officer. [07:13:48] i posted all the info and the patches on the ticket in the security queue. [07:14:17] Just wondering: 1.6.7 was supposed to get its own branch, right? [07:14:49] And I'm still confused by the plan to release without binaries. [07:15:06] Daria: Thanks. It's good to know we have this as a fallback. [07:16:38] 1.6.7 will get its own branch from the 1.6.6 release point [07:16:49] it will have *only* the security patches and the version update [07:17:42] Ok, that's what I had in mind. It's slightly different from what I think Simon said though. [07:18:23] In my perfect world, we'd have a 1.6.7 branch in gerrit with limited access. [07:18:36] Anything else would be business as usual. [07:18:53] Once 1.6.7 is out, make the branch public and pull up to 1.6.x. [07:18:58] Would that be feasible? [07:19:27] i think so. ideally simon will do it because it involves monkeying behind gerrits back [07:20:02] Hmm, my idea is exactly not to do that... [07:20:18] you have to, if you want it to be private [07:20:40] You can't limit access to a branch to a couple of IDs? [07:21:43] It's possible for "merge", but not the other privileges? [07:21:55] we limit push access to 1.6.x, we should be able to limit read access for a 1.6.7 branch [07:22:17] I'd have to go look at the gerrit docs, bearing in mind that our version of gerrit is a bit long in the tooth. [07:23:04] http://gerrit.openafs.org/Documentation/access-control.html [07:23:16] it's "read access" that you would be restricting [07:23:49] the problem is not gerrit itself, we export the same tree directly via git protocol. [07:24:02] so i don't know what has to happen to do that [07:24:14] git://git.openafs.org/openafs is the same tree [07:25:17] Ah. Well... [07:26:11] So, 1.6.7 is on its way. [07:26:47] 1.6.8pre1 was announced, and we're waiting for feedback. Does anyone feel like providing some binaries? [07:27:30] I expect to have some freebsd binaries by the end of the week, but there are a few things that could go wrong and prevent that. [07:27:54] Fine. Whatever I get, I'll upload. [07:27:55] yeah, sorry, I meant to have solaris already [07:28:40] Next topic: "Testing" [07:29:13] What I got from the discussion so far: [07:29:38] There's some basic framework that could be used. [07:29:55] And Andrew proposed to approach individuals. [07:30:26] Anything missing? [07:31:11] (I'm still a bit in "catch up" mode, and didn't get most of the details this week) [07:31:11] i started looking at Robot Framework for system testing, and put what i have so far on github: https://github.com/openafs-contrib/openafs-robotest [07:31:34] which is just a "smoke test" as this point. [07:32:18] I'm not sure what details you'd be looking for [07:32:52] The github URL is a nice example ;-) [07:34:50] An automated smoke test simulating "a cell" would be good. [07:34:51] sorry, it's not further along. i would have had a talk at eakc if it was. [07:36:20] But how far can we possibly get? [07:37:17] Given our resources, I really don't see a replacement for the community testing in their environments. [07:37:39] we can have regression tests for known bugs, we can simulate every known e.g. volume operation, many other things... [07:37:45] yes, that is my assumption as well. [07:37:46] it's not a replacement [07:38:17] this is something people can use if they want to test. [07:38:30] and we'd want them to provide more tests over time. [07:39:57] the community 'testers' thing is a much more immediate approach, though; can I get some kind of feel for agreement/disagreement on it? [07:40:38] Sounds like a fine plan. [07:40:49] i dont think there is disagreement, as much as finding volunteers. :) [07:41:33] The most valuable report for 1.6.6 was the "we took the plunge and deployed pre2 on the whole cell last week" one. [07:42:02] Unfortunately, I expect this to be a rare exception. [07:43:08] andrew pointed out there is an openafs-testers list. seems like we should foster some traffic there? [07:44:22] Hmm. A single message in the past decade. Off topic. [07:44:23] I'm not sure how much "testers-specific" traffic we'd really need, but I guess it's a way to communicate with them specifically if we need to [07:44:33] well yeah, it's not used right now :) [07:45:15] Why not keep it on -info? [07:45:47] Our announcements ask to report successes there anyway. And it's read by a few people. [07:45:51] because then you'd have some focus on testing. [07:46:16] like when were were working on docs on the docs list. [07:46:37] Ah, another list I'm not even aware of ;-) [07:46:51] if the communication we're talking about are testing results, I feel like getting people to post to -info is a little higher barrier to entry [07:47:20] because it just "feels" like you'd just be adding noise/spam, since there are a lot of people on that list, and testing results aren't something you see on there normally [07:47:44] Which is the whole problem. [07:48:17] And I don't consider test results on that list spam. Never did, even when I was nothing but a novice admin. [07:48:33] Especially when I was nothing but a novice admin. [07:49:18] I'd rather get the results privately than not get them at all [07:49:37] +1 [07:49:50] I don't think anyone would argue with that. [07:51:40] No. I just argue we'd not get a single additional report. [07:54:00] as long as it's not worse, at least it is a plan to make things better. [07:54:57] It is worse IMO because 99% of those who do see a test report occasionally today no longer would. [07:55:34] ...? I'm not talking about the results never hitting -info, it's just how we collect them [07:55:41] oh i assume a summary would be posted to -info [07:56:54] for now I'd just like to see what people we can get on board; where the results get sent doesn't seem as important as that can change [07:58:10] correct. [07:59:14] [my apologies: I'm darned tired, and maybe that's why I'm so negative today] [07:59:47] sorry, briefly distracted. i am pro-testing-volunteers. catching up the rest of the way now [07:59:50] no no, that's fine, I just don't think we need to establish all of this today [08:00:10] it's easier to talk about this after we have people that are participating, so they can contribute their opinions, as well [08:00:17] So the proposal is to send a mail to -info telling folks how great testing is and inviting them to subscribe -testing and send their reports there? [08:00:28] no [08:00:48] I knew i was missing something ;-) [08:00:53] heh [08:01:45] what I wanted to do was to ask people to be put on some list (not a mailing list, just a list of people), where we depend on the people on that list for providing testing feedback [08:02:04] specifically, we depend on them to run pre* releases through whatever testing they provide before deploying a version locally [08:02:11] that is how I would describe it [08:02:26] whether that involves the openafs-testers list, or things get sent to me or release-team or openafs-info, whatever [08:02:31] hm. i wonder if the platform-specific suggested releases plan ever got written down [08:02:54] the important thing is just having specific people who are on the hook for providing it, so people don't just think "someone else" is going to do it [08:03:00] Daria: If it got, I haven't found it. [08:03:10] there was an idea that we'd have known testers test their platform and recommend releases based on feedback, as part of the throwing-away-version-numbering scheme we discussed like 3 years ago [08:04:16] one or a set of people would be the known testers for a platform and unless they endorsed a given release we would not recommend it, so you can have "stable version (date)" for linux recommended but "stable version (a week earlier)" recommended for solaris [08:04:39] Ah. [08:05:28] The main problem I see is that even those who test occasionally won't do it for every release. [08:06:23] you're right, and it would be worse in a world (envisioned in that plan) where releases would automatically happen weekly or biweekly [08:06:36] Much worse. [08:07:21] you'll note that proposal didn't go far. sort of a shame at least in ters of version numbering that it didn;t [08:08:48] My personal conclusion at this point: [08:09:21] i am trying to avoid personally concluding. i am hoping i still have many good years left in me. [08:09:35] "I do, too." [08:09:55] ;-) But seriously: More testing would be most welcome. How to get it, and where to direct the efforts is completely unclear to me. [08:11:00] I just don't expect anyone to commit to anything. [08:11:11] just let me try to organize a few people? we'll see how it goes [08:11:35] Prove me wrong, please! [08:12:23] Ok, certainly to be discussed more. [08:12:59] I put the 1.8/1.9 etc. issue on the agenda. Does it make sense to discuss without Jeff? [08:13:36] from what I heard the last discussion involved a lot of "discussion" primarily from simon and jeff [08:14:13] deciding on something without them doesn't seem like it'd do much... [08:15:04] we could discuss without deciding but i have nothingnew [08:15:33] sorry i am typorific. adium is being annoying today. [08:15:52] So what's not new? [08:15:53] calling the next stable 1.8.x seems to make sense to me, and i'd expect would be less confusing in general. [08:16:02] but just my 2 cents. [08:16:59] The only message I've taken away so far is that numbering the branches is fairly arbitrary, and it's not even clear whether Unix and Windows should stay in the same tree. [08:17:35] NB I'd also prefer the next "stable" branch to be 1.8. If we go on as in the past anyway. [08:18:04] my opinion is that they should either look like almost completely different things (like "kerberos 4 windows" or "strawberry perl"), or keep them on the same branch (e.g. 1.10.2 for unix and windows) [08:19:04] if everything were on the same stable branch, even if there were e.g. windows-only releases it would seem less confusing than now [08:19:34] If I got it right, that's not seriously being discussed. [08:20:19] The longer we wait, the more painful it becomes. [08:21:40] IMO, the new branches should be established a.s.a.p., and the search for a really great solution continue later. [08:22:17] i still like the idea of a src/WINNT that is somehow unlinked, allowed to skew, and has more frequently releases named whatever, and changes in the core code have to go through normal review albeit probably being integrated more quickly to adapt to the windows release schedule [08:23:06] Please remind me: are 1.7 changes going through master right now? [08:23:12] Yes. [08:23:49] Daria, how's that different from what you propose? [08:24:23] Today: master -> 1.6/1.7 [08:24:29] that *is* what i propose. [08:24:33] Tomorrow: master -> 1.8/1.9 [08:24:47] Ah ;-) Did I mention I'm tired? [08:25:32] "more frequently releases named whatever" doesn't mean they have to be e.g. openafs 1.7 [08:25:43] yup [08:25:57] openafs 1.9? ;-) [08:26:35] portable openafs x and windows openafs y [08:26:38] or somesuch [08:27:15] Why not. [08:27:30] To say it again, I'm aware that this is not really my business. [08:28:26] Someone asked whether I'd be willing to cope with two branches. I would. But if I'm not asked to , fine too. [08:29:44] Let's hope the minutes will spawn more discussions on those issues. [08:29:44] are we trying to stall to wait for haba? :) [08:30:00] heh. [08:30:14] I was hoping for him and Ken to drop by. Well. [08:30:31] But let's discuss the meeting slot briefly. [08:30:56] If we'd shift it back by one hour, would that be a problem for anyone? [08:31:06] Would anyone prefer that anyway? [08:31:13] What about two hours? [08:31:37] by "back" do you mean earlier? [08:31:40] er, do you mean 1 or 2 hours later? [08:31:44] later or earlier? [08:31:46] Later. Sorry [08:31:50] Either one or two would be fine for me; it would be less likely that my commute would be delayed by attending (but it's not a real problem when it is). [08:32:07] i like the current time, but not strongly [08:32:26] 2 hours later would probably cause me some problems a couple times a month [08:32:26] I assumed that if someone would find 'later' to be 'worse', it would be the europeans [08:32:38] currently this is my earliest regular meeting [08:32:46] so yeah, I'd like it later [08:33:52] One hour would be ok for me. Two, it would start hurting. [08:35:36] 2 hours would put it during lunch time for some of us - but not necessarily a problem for me [08:36:03] not problem for me. [08:36:35] So, I'll ask on release-team who'd participate more regularly if we shift it by an hour, which seems at least no real problem for anyone here. [08:37:11] So, anything else to discuss today? [08:38:11] It seems not. Thanks a lot everyone! [08:38:18] thank you [08:39:02] --- wiesand has left [08:39:06] --- deason has left [08:39:12] --- Daria has left [08:40:14] --- Marc Dionne has left [08:44:18] --- meffie has left [09:18:10] --- deason has become available [15:10:01] --- deason has left [15:10:01] --- deason has become available [17:59:32] --- deason has left [22:08:44] --- shadow@gmail.com/barnowl7628413F has left [22:08:59] --- shadow@gmail.com/barnowl7628413F has become available