[01:02:08] --- Simon Wilkinson has become available [01:35:04] --- Simon Wilkinson has left [05:50:14] --- meffie has become available [06:43:52] --- Simon Wilkinson has become available [07:03:12] --- Derrick Brashear has become available [07:36:38] --- Marc Dionne has become available [07:42:49] --- meffie has left [07:53:03] --- Derrick Brashear has left: Disconnected [07:54:37] --- Simon Wilkinson has left [07:56:27] --- Stephan Wiesand has become available [07:58:17] Small crowd today.. [07:58:34] its early yet [07:59:38] Paul may not be able to attend, partly or at all. [08:01:04] And I have one hour only today. (got to see a man about a brick a 4 pm utc) ;-) [08:01:51] But then, there isn't all that much to discuss today IMHO. [08:02:02] Is there a list? [08:03:30] From my point of view, and I think Paul agrees, it's really just how and when to go forward with 1.6.2.1 and 1.6.3. [08:04:21] 1.6.2.1 is just for supporting new linux kernels, right? How much testing do we need to do (various distros/etc.) before we are happy that the kernel support is there? [08:04:47] Of course, if others have more points, tha's fine. But going through individual changes today seems pointless to me. [08:05:41] Good question. I have it running on an F18 System with 3.8.2. Is that sufficient? [08:06:06] i did have a question about the lone 3.9 fix. seems like it would be worth pulling in for 1.6.3, maybe avoid the need for a quick 1.6.3.1 later [08:06:19] I wonder if Trello would be useful to help organize / manage the pending 1.6.x patchsets [08:06:33] I had hoped that kind of feedback would come from those who wanted 1.6.2.1. [08:06:45] Marc: Ok. [08:07:04] Jeff: Never heard about it. [08:07:09] 3.9 support in 1.6.3 seems reasonable. [08:07:16] it needs to go to master first of course [08:07:31] Marc: well, yes. [08:07:39] as 3.9 is now at rc2, it's likely to be the only fix needed [08:08:05] Good news. Please push it a.s.a.p. [08:08:17] will do, once it gets to master [08:08:35] is it in gerrit for master yet? [08:09:00] yes, it's been there a while. probably swamped by all the 1.6 changes... :) [08:09:19] --- meffie has become available [08:09:23] http://gerrit.openafs.org/#change,9403 [08:09:50] --- Derrick Brashear has become available [08:10:01] Sorry, I've been sufficiently busy looking at the 1.6 branch only. [08:10:09] :) [08:11:15] Thanks Jeff. Another one touching acinclude.m4, thus "wait or rebase". Would it be feasible to split this file, so that changes can become more independent? [08:13:35] Trello is a "cloud service" ? [08:15:23] trello.com [08:15:47] a google doc spreadsheet could also work [08:16:59] Anything that has to be kept in sync manually will only work to a certain degree. [08:18:32] The first step to handle the changes backlog is clearly to merge simple ones already agreed. I think that's the majority. [08:19:01] This merging had previously been blocking on deciding whether 1.6.2.1 was ready? [08:19:55] Yes. Many changes could have been merged for a week or so if it weren't for 1.6.2.1. [08:20:30] Ken is not here today. I would like to hear that he has tested 1.6.2.1 [08:20:45] And I think we should stop waiting for it. We've had proposed tarballs since Friday and no feedback. [08:20:56] --- meffie has left [08:21:09] either 1.6.2.1 is correct as is and can be tagged or move on [08:21:18] From where I sit (not really running linux clients), it sounds like we can declare 1.6.2.1 as done as it's gonig to get and move on. [08:21:47] I think it can be released as is. I'm also ok with not releasing it at all, or branching later if we have to, as SImon suggested. [08:22:34] There seems to be consensus that we should start merging 1.6.3 changes *now* ? [08:22:35] --- meffie has become available [08:22:46] 9639 is the 3.9 fix for 1.6 [08:22:52] This would be the time to object, if there are objections. Otherwise, you should go ahead. [08:23:54] Marc: great, thanks. [08:24:46] tell me a sha1 and i can push a tag [08:24:49] (for 1.6.2.1) [08:25:49] I'll send brief minutes to release-team later in the evening. Tomorrow, I'll start merging and tell gerrit the hash id to tag, unless anyone objects. [08:26:23] Is the idea to split acinclude.m4 stupid? [08:26:56] We already pull in krb5 m4 macros from elsewhere, so it does not seem a priori unreasonable. [08:27:00] ehm, tell *Derrick* the hash id... [08:29:11] Such a split would have to happen on master first of course. But medium term it would simplify merging changes I think. [08:30:12] I haven't looked at the current acinclude.m4 to get a sense of what lines it could be split on, though. [08:31:11] There are clearly parts specific to Solaris and parts specific to Linux. Having these in different files would already help. [08:31:53] maybe/ but the linux file is going to be a disaster just as always. [08:32:07] yeah, and it seems to be the main culprit [08:33:03] We have changes in the queue touching the Solrais part. Either those or 9639 will have to be rebased. [08:34:03] rebasing is not a problem when the changes occur in different parts of the file. the problem are things such as linux where multiple changes are impacting adjacent lines [08:35:34] keeping things alphabetical as opposed to chronological can help with that [08:36:02] Jeff, rebasing is simple in that case. I'd still prefer getting a success report when I hit "submit". [08:36:37] we have gerrit configured in a conservative manner. we don't want gerrit to rebase a change incorrectly behind our backs [08:37:12] Jeff, I know. And I agree it's the right configuration. [08:37:58] Marc, I'm afraid I don't get the idea. [08:38:03] --- deason has become available [08:39:01] you might want to take a different approach to submissions. git cherry-pick to a local branch all of the things you want to approve. confirm that the tree of patches you wish to approve builds locally. push the tree back to gerrit and then submit. its what I do when there are a large number of individual patches to be pulled [08:40:20] Jeff, good idea. Its rather "push back to gerrit, wait for buildbot and then submit" though. [08:40:50] the buildbot wait is definitely boring [08:40:51] Stephan, if changes add lines at random spots in a file, it causes less conflict than adding everything at the end. In the linux kernel, some files were sorted alphabetically specifically for this [08:41:41] I would kind of like to decree that these things should be sorted alphabetically, just so I know where to add new things :) I'm never 100% sure that "just add it at the end" is the right thing to do. [08:43:12] I will point out that sorting is not going to necessarily help 1.6 since not all changes on master will be pulled to 1.6. a separate 1.6 sorting patchset will need to be applied there at some point after things quiet down (if they quiet down) [08:44:58] some of the linux parts of acinclude.m4 were sorted when Simon re organized it. some are not [08:46:34] We don't have to finalize this discussion here and today. I just wanted to bring up the idea. [08:47:53] Both splitting and sorting will help, with different things. If any of this is done, both should be applied to master and 1_6_x ate the same (quiet) time. [08:50:40] Andrew suggested to merge two changes fixing parallel builds first. Any objections to that? [08:51:08] none here [08:51:10] 9405 and 9456 [08:51:31] that's a good idea for buildbot [08:52:33] In general, I'm grateful for any review in gerrit. 9456 didn't have much yet. [08:53:23] (the author and me liking a change should not be suffucuent ot merge it ) ;-) [08:54:09] I wasn't terribly worried about that; the only thing I see a change like that breaking is making builds fail [08:54:55] 9456 looks fine. [08:55:32] Thanks. [08:55:44] Anything else for my last 5 minutes? [08:58:06] i have nothing [08:58:31] Ok. Let's hope we start draining the queue tomorrow. [08:59:34] I may have to prod folks to review more, especially if Paul is unavailable. My apologies in advance ;-) [09:00:25] Have to run now, sorry. Thanks everyone. Feel free to keep discussing, I'll catch up later. [09:00:34] --- Stephan Wiesand has left [09:00:53] --- Marc Dionne has left [09:12:01] --- Simon Wilkinson has become available [09:15:49] --- Derrick Brashear has left [09:25:19] --- meffie has left [09:48:22] --- ktdreyer has become available [09:57:27] --- stephan.wiesand has become available [09:58:42] --- stephan.wiesand has left [11:34:53] --- Simon Wilkinson has left [16:49:58] --- deason has left [17:22:29] --- Simon Wilkinson has become available [17:46:10] --- Simon Wilkinson has left [17:46:53] --- Simon Wilkinson has become available [20:46:42] --- Jeffrey Altman has left: Disconnected [20:49:57] --- Jeffrey Altman has become available