[05:48:22] --- squinney has become available [06:17:44] --- shadow@gmail.com/barnowl5ABA57FD has left [06:17:53] --- shadow@gmail.com/barnowl5ABA57FD has become available [06:24:05] --- Stephan Wiesand has become available [06:30:54] test... [06:32:16] Seems to be working today [06:32:34] Thanks. [06:39:34] --- meffie has become available [07:02:25] --- deason has become available [07:05:15] Hello [07:05:28] hello [07:05:49] hi [07:06:06] hello [07:07:09] Of course I didn't find the time to prepare a more detailed agenda :-( [07:07:41] I see two major topics today... [07:07:57] it is Summer [07:08:09] We are all supposed to be on vacation [07:08:39] apparently, some of us aren't? [07:08:58] Do you mean we should stall 1.6 for another month? [07:08:59] unfortunately not [07:09:33] My time off starts next Tuesday. [07:09:42] I don't think its a question of stalling. Just that I would expect there to be reduced participation [07:10:14] It's not so bad, really. [07:10:16] I'm still dealing with fallout from the security advisory. not much time for new openafs work [07:10:56] I guess many are. [07:11:25] yes, i think everyone is dealing with such. [07:11:35] But I'd really like to start putting 1.6.6 together. [07:11:41] anyway, "two major topics"? [07:11:55] I think the items in gerrit that you have marked as "for 1.6.6" are fine. make a list and send to openafs-devel asking for reviews [07:12:51] right. 1) how to deal with the backlog 2) looking at http://gerrit.openafs.org/#q,branch:openafs-stable-1_6_x+starredby:1000008,n,z again [07:13:14] Starting with 2): Jeff, these are from that list. [07:13:58] Is that link to the "for 1.6.6" list? Or is that something else? [07:14:20] The ones I marked "approved" had some review, and I think they are good to merge. [07:14:49] We're keen to see the addition of "fs flushall", good to see it on that list [07:15:22] just wondering, has anyone deployed http://gerrit.openafs.org/#change,9420 on a public server and measured whether it is in fact helpful? [07:15:25] It's the list of possibly controversal features we already discussed in June. [07:15:48] http://conference.openafs.org/release-team@conference.openafs.org/2013-06-12.txt [07:16:11] Most of them were considered ok. [07:16:19] 9420: no, but people still have nat troubles without it [07:16:30] 9451 lacks review. [07:16:56] could we merge 10118 before anything else, still? [07:17:09] 6272 should have an "off" switch. [07:17:50] And 9571 could cause wait times up to 18h IIRC and we wanted to revisit that when Mike is present. [07:18:17] 10118: yes, I still think that makes sense. [07:18:53] 9571: yes; and, well, mike is here now, it looks like [07:18:54] i can cap the time in 9571. [07:19:16] 9571: ok [07:19:32] to how much? I would say 'minutes' or thereabouts [07:19:47] 9571: the time between retries should stop doubling after some point and the max retry time should be capped. [07:20:32] or maybe 'a minute' [07:20:43] retrying once a minute for ~16 minutes seems reasonable [07:21:07] agreed [07:21:11] ok [07:22:09] 9420: Jeffrey, do you object to having it in pre1? [07:22:27] so, I gather with our current workflow, mike needs to submit a new change to master and pull it to 1.6, and can't modify 9571 directly [07:23:37] I don't object to 9420. My experience with many NATs is that they ignore data generated from the external side when deciding whether or not to maintain the port mapping. I'm just wondering to what extent it helps. [07:23:58] i'll fix 9571. [07:24:37] meffie: but it needs to be fixed on master, too [07:25:04] I could try to ask for people with nat trouble to try 9420, or ask them to try pre1 if it goes in pre1 [07:25:19] (obviously it's less of an obstacle if there are binaries) [07:25:43] ok, i'll fix master too. [07:26:37] Let's have 9420 in pre1. It may indeed help getting it tested. If it helps noone, we can still back it out. [07:27:42] when that happens, I could submit a revert so it shows up in gerrit so we're less likely to forget [07:27:53] thank you [07:28:04] or I could do that now, really, and only merge 9420 for now [07:28:50] Stephen: yes, fs flushall is a nice feature I'd like to have in 1.6.6. [07:29:13] I have to drop off. [07:29:24] It's actually in the list of things I'd like to merge immediately after the Linux 3.11 change. [07:29:30] Bye Jeff, thanks. [07:30:00] Andrew, could you add a comment to 9420? [07:30:04] I'll unstar 6272, as I think it's established that that's still deferred for now [07:30:23] and 6266 I'd like to wait on just one more release, unless someone pushes for it [07:30:26] 9420: sure [07:31:13] I figure Derrick will push for 6266... [07:31:30] He does every time ;-) [07:31:48] And actually, I'd like to have it on my clients. [07:32:07] we'll need to test the disabling mech i haven't written yet :\ [07:32:20] Exactly. [07:32:37] the code itself has been well-tested. everyone using an iPhone AFS client has it :) [07:32:38] I think you mean 6272? [07:33:01] i do. which did you mean? [07:33:02] Yes, GUACB [07:33:30] oh, 6266. would be nice, but i am not in a rush. it can wait [07:33:56] Lets keep them on the listed, marked -2, with a comment saying why. [07:35:50] Will the accidentally merged change be a problem? [07:36:39] I don't think so; all it does is rename a function [07:36:42] I mean, will the current HEAD of 1_6_x + 10118 be usable? [07:36:45] what about 9407? [07:36:57] The function isn't used anywhere else? [07:37:55] Let's keep it around, but it's not for 1.6.6. [07:38:02] (9407) [07:38:41] nowhere besides where that patch renames it [07:38:47] (and I mean, the source _builds_, so...) [07:39:11] Ok. The Fedora addicts won't mind. [07:40:05] Just merged 10118 [07:41:30] About the backlog: [07:42:16] I'll have much more time for openafs in the near future, and I'd like t make use of it. [07:43:26] By working through the backlog (starting with the oldest changes), and merging whatever seems resonable. [07:43:35] --- shadow@gmail.com/barnowl5ABA57FD has left [07:43:37] --- shadow@gmail.com/barnowl5ABA57FD has become available [07:44:43] Like the list I sent around a week ago. This build has been running for a week on a server and a few clients (which can fs flushall :) [07:45:46] I'd like to be a bit more courageous when merging such changes, even if there's minimal review available only. [07:46:14] Because otherwise, I'll never get it done. [07:46:29] Opinions? [07:47:22] if you yell at specific people about a specific change, I think it's way more likely you'll get a review [07:47:34] but if you can't, yes, that makes sense [07:48:13] in that system, it would make sense for people to -1 things saying 'please wait for me to review' [07:48:18] or 'please wait for X to review' [07:48:18] it also helps to have a deadline, or window. [07:48:24] yes, that too [07:49:18] What's a reasonable deadline? [07:49:21] if i merged it on master i probably thought it was a good idea, but there are problem times i should pre-emptively comment that something needs more attention for 1.6 [07:50:28] deadline: 1 week, if the deadline is for 'saying something', not necessarily completing review [07:52:58] That's six weeks for the backlog, best case. [07:54:24] I don't follow; you're asking 1 thing at a time for 6 things you want review for? [07:54:38] and 'takes a full week' isn't 'best case' if that's what the deadline is :) [07:56:02] The idea is to select the next, say, 10-15 changes to merge, test that stack, then merge it. Repeat. [07:56:31] Obviously, everything merged should have sufficient review before. [07:56:43] The question is: what's sufficient? [07:57:31] Many changes will need to be rebased. Some trivially, some not. [07:58:20] So, waiting for at least three +1s from other developers than the author, will mean six weeks. [07:59:42] I don't think you need to limit to 10-15 changes for testing, if the changes already have review [07:59:56] just do all of them; it's supposed to be very unlikely that you'll hit any issues [08:00:01] unless you mean, you wait until you have 10-15 [08:03:13] Getting sufficient review for all changes in the backlog at once seems hopeless. [08:04:10] --- kaduk has become available [08:08:40] Take 9130 9131 8898 9281 9282 . None of them was reviewed by anyone but you, for six months. [08:08:44] well, like derrick said, if it was merged on master, then the gatekeepers assumed it was a good idea, it's just a matter of deciding when it should released? [08:09:03] (assumed is the wrong word, i mean decided) [08:09:08] It was also six months ago that buildbot verified them. [08:10:06] getting buildbot to verify them again should not be hard [08:10:19] Except for the list we discussed first, those should be bug fixes or not changing behaviour. [08:11:47] well, people are more likely to do something if you tell them specifically to do something [08:12:31] Ok, will do. [08:12:33] I mean, specifically that person; like "derrick please provide review on 9130" not "everyone please review everything" [08:12:43] But I predict the backlog will grow, not shrink. [08:13:05] you can get someone else to go after people if you want :) the "whip" [08:13:41] Well, I got a review request in my inbox this morning, and it will probably get dealt with today. I don't know when I would have spontaneously decided to go review that change... [08:14:20] That's one problem. It feels kind of rude to "invite" all of you to review ~70 changes. And please within a week ;-) [08:14:49] 7 people at 70 changes each is a bit much, yes. [08:14:56] 7 people at 10 changes each, less so. [08:14:59] it could still be something to say "do as many as you can before 21 aug 2013" [08:15:15] without a specific date, it's just "whenever you get around to it" [08:16:31] yes. [08:16:47] Alternately, "ask us to do things, and we will tell you when it becomes unreasonable/unmanagable" [08:17:04] it would help to have some sort of window, so people can better juggle. [08:19:59] Ok, let's try. [08:22:32] Btw is there a way to get gerrit to display the open changes sorted by number? [08:23:37] hmm, that would be handy [08:23:46] is there even a way to sort them by anything? [08:23:59] I could get you a script that could print them out in that order, if you want [08:24:17] Well, they are sorted by the last modification date. [08:24:56] I mean, sorted by anything but the default :) [08:26:14] http://code.google.com/p/gerrit/issues/detail?id=536 :-( [08:27:23] that gerrit-not-reviewed script, for example, can just print out the changes, and just piping through 'sort' will provide a kind of ordering, though not numeric [08:27:36] Andrew: thanks, but I'll still have to do the bookkeeping with a text editor. That's one reason doing it in batches of 10-15 is much easier that all at once. [08:29:35] But at least the editor can sort ;-) [08:29:47] Anything else for today? [08:30:47] not me [08:31:11] Volunteers for writing up minutes? [08:31:59] Ok, my turn then. [08:32:09] Thanks everybody! [08:32:34] Bye [08:32:36] --- Stephan Wiesand has left [08:33:43] --- kaduk has left [09:06:09] --- squinney has left [09:53:28] --- deason has left [09:53:29] --- deason has become available [12:44:38] --- meffie has left [13:35:27] --- meffie has become available [13:52:27] --- shadow@gmail.com/barnowl5ABA57FD has left [13:55:40] --- shadow@gmail.com/barnowl5ABA57FD has become available [15:13:55] --- meffie has left [15:56:34] --- deason has left [19:41:31] --- shadow@gmail.com/barnowl5ABA57FD has left [19:46:31] --- shadow@gmail.com/barnowl5ABA57FD has become available