[04:46:17] --- meffie has become available [04:52:10] --- Marc Dionne has become available [06:58:49] --- wiesand has become available [07:01:17] Hello [07:01:42] hi stephan [07:02:08] mornin'. [07:02:23] Marc, glad you're here... good or bad news on Linux? [07:02:27] Hi Ben [07:02:39] still good with the 3.12 release [07:02:44] :) [07:03:15] Derrick, are you actually here? [07:03:16] gm [07:03:18] first time in my memory where there have been no changes needed for a release [07:03:24] i am here [07:03:49] Derrick: any news regarding Mavericks? [07:04:29] Marc: well, we had 1.6.5.1 lately [07:04:35] i think i know what the symlink issue is. i should touch base with ken today [07:04:51] Block pre1 for it? [07:05:53] not much point, there won't be an installer ready yet anyway [07:06:10] oh, are we starting at 9:30? [07:06:15] I think 1.6.6 final should block on the symlink fix so that users who upgrade to Mavericks after installing 1.6.6 won't risk crashes [07:06:20] starting what at 9:30? [07:07:19] Will the symlink fix be clearly OSX-only or low risk? [07:07:30] it is OSX only [07:07:34] (oops, nm, my clock is off) [07:07:44] Mike: yes ;-) [07:07:52] the fix is osx-only. i think the iplementation will touch elsewhere [07:08:14] will or will not? [07:08:20] i have some further info to gather; the issue is mavericks forces lldb which changes the kernel debug game [07:08:23] will. [07:08:27] low risk tho [07:09:32] If you say it's safe to include between pre1 and pre2 - or pre1 and final - : fine. [07:09:46] if i am right about what it is, it will be [07:10:16] Ok. [07:11:42] Jeff, I guess the commit message of 10375 is ok now? [07:13:36] Hmm, no Andrew... any thoughts regarding afs/afs.h? (#131737) [07:13:41] I think the change in question (location of rpc/ headers) is probably fine anyway, since they have been in the KSRC tree "for ever". Fetching them from the installed system is arguably a mistake. [07:13:48] (That's in 10375, of course.) [07:13:52] There were no changes to the 10375 commit message when patchset 2 was issued [07:14:34] There were, or I'm dreaming [07:14:37] The automated hook thinks there were changes in the 10375 commit message for patch set 2. [07:15:07] For afs/afs.h, I think we agree that the current state is bogus, but someone has to do the work to figure out (even roughly) what it "should" be. [07:15:33] --- deason has become available [07:15:55] gerrit is being flakey with regards to showing diffs in commit messages in Firefox [07:16:26] +1 [07:17:04] Thanks. Merged. [07:17:05] gerrit has built-in functionality to show diffs between different versions of a single patchset?! [07:17:18] Thanks. [07:18:10] Could someone look at 10343? [07:19:01] kaduk: yes, you look at 'patch history' in the unified or side-by-side diff viewing thing [07:19:37] I never knew. Thanks! [07:19:44] and in newer gerrit versions it's more nicely intergrated into the ui [07:19:57] for afs/afs.h the problem is that OpenAFS does not have a well defined API and it is unlikely that there will be such a well defined API in the near future. There is no way to determine what is required by external apps that might be including afs/afs.h to build. If we want to make changes I propose that we do one of two things: 1. either provide the necessary cred defines such that afs/afs.h can build out of tree which would be leaking more internal structures 2. intentionally break the world and provide the minimal contents. Then wait for bug reports from other projects to come in to inform us what they require. [07:20:24] on afs/afs.h, it's been like that for several versions and there are workarounds, so it didn't seem too _immediately_ critical, though just emptying out afs/afs.h would probably fix more things than it breaks [07:21:06] perl-AFS is likely to be the worst case [07:22:01] I'd opt for Jeffrey's option 1 - for the stable series. [07:23:08] But it wouldn't make me sad to have this in 1.6.7, not 1.6.6 [07:23:25] we could also move only the parts that are breaking to an internal include [07:24:33] If anyone has objections to postponing this to 1.6.7, please raise them now. [07:24:41] no objections [07:24:59] Derrick: Thanks [07:25:27] The cache truncation fixes were merged on master recently. [07:26:25] Jeff said a while ago no need to wait for them at that point, but maybe that's different now that they're ready? [07:26:46] they prevent a thread from entering an infinite loop that has only been seen on Solaris although the code is general. [07:27:11] There was no need to wait for them but since 1.6.6 pre1 has not yet shipped I have no objections to them being included [07:27:39] they have been running for a couple of months in the production environment that was experiencing the problem [07:27:53] Ok. Who can pull them up? [07:28:35] I can but it won't be until Saturday. I'm still on the road [07:29:17] I'll look at it, unless someone beats me. [07:29:56] Anders has pulled up the Linux namespaces changes. [07:30:16] 10427/8 [07:30:47] since it's needed for at least ubuntu they should probably go in for 1.6.6 [07:31:23] Fedora doesn't turn this on? [07:31:53] i'll check again, but i don't think so [07:32:41] But either way, I'm also on favour of including them now. Unless anything is found wrong with them. [07:33:08] but even for fedora it will probably show up eventually [07:34:08] Probably. So, if you can, please review them. [07:34:39] sure [07:34:46] 10382 seems really low risk to me [07:35:58] I'm getting a page not found error for "http://gerrit.openafs.org/#patch,sidebyside,10382,2,src/lwp/Makefile.in" [07:36:05] anyone else seeing the same thing? [07:36:21] shows up fine here [07:36:28] fine here [07:36:29] It works okay for me. The change is just adding a dependency on process.amd64.s for process.o. [07:36:33] I can see it [07:37:56] works fine in Chrome. Firefox 24.0 can't show it. and IE11 is not supported by Gerrit at all. Yeah [07:38:35] Simon once said that gerrit hates you. Guess he was right. [07:39:22] I think I'll take that one, unless anyone objects soon. [07:39:24] Gerrit is confused because I have two google accounts "jaltman@gmail.com" and "jaltman@your-file-system.com" and both e-mail addresses are listed in Gerrit. So it doesn't know which OpenID to use [07:40:05] 10382 +1 [07:40:15] Thanks. [07:40:40] Anything on RT #131766? [07:41:42] it's been that way, or worse, since forever 131766 [07:41:44] Jeffrey Altman: yes, i've noticed gerrit gets confused sometimes, listing you as "anonymous" on +1 for trivial rebases. [07:41:58] er, oops, didn't mean to paste that again :) [07:42:48] Ok, no point in waiting for that. [07:42:52] we need to move the platform detection to before setting CC, or change how we set CC... I think I got partway there at one point, but doing that is nontrivial while keeping all of the various autoconf stuff still working [07:43:24] Maybe not for 1.6 at all. [07:43:43] Anything else we'd need for pre1? [07:44:05] The only item left on my checklist are the cache truncation fixes now. [07:44:10] we could probably get something at least for solaris without changing the world; but I don't think we need to hold for it [07:44:28] Andrew: ok. [07:44:45] hmm, i think there is something already on master, for some of this. have to look. [07:45:05] but, i would not hold up a pre1 [07:46:31] So the plan is: [07:46:37] I would prefer that rewriting configure and afs/afs.h be done as part of a 1.9 series of releases. A regular development release series is a much better place to experiment and break things. [07:47:01] Jeff: noted [07:47:22] I propose branching 1.9 in late november after the U.S. Thanksgiving holiday [07:48:04] What's your estimate for getting it into 1.10 shape? [07:49:19] 4 to 6 months [07:49:49] Will it come with rxgk? [07:49:51] no [07:49:58] :-( [07:50:11] part of the reason for branching 1.9 is to free master so that rxgk can break the world [07:50:30] Ah. [07:50:47] NB we'd have to call it 2.0 then anyway. [07:50:58] (the Elders said that) [07:51:22] The primary benefits that 1.10 will provide are: bring windows back into the same release series as unix; pthreaded ubik; rx improvements; libtooling for perl-afs [07:52:29] windows is essentially stable at this point and it is not appropriate to continue using the 1.7 series for architectural changes [07:52:53] Would there not be a 1.8 series, then? [07:53:19] I will cut a 1.8 branch after the next 1.7 release but then what? [07:55:48] So we'd be in a state where you are maintaining a 1.8 series, Stephan is maintaining a 1.6 series, and we're cutting 1.9 releases from master? [07:56:04] we are cutting 1.9 from a 1.9 branch [07:56:12] which would then become 1.10 [07:56:25] Ah. [07:56:38] 1.9 releases would be issued for testing? [07:57:06] 1.9 releases are there so we can make publicly available code changes that might break things [07:57:12] preferably not of course [07:58:15] The release process will be the same as for 1.6 now? [07:58:45] Once 1.9 is cut I would expect that 1.6 would have a much more restrictive acceptance policy for changes. [07:59:26] The release process for 1.9 would mirror that which we are using for 1.6 [07:59:38] Commits are to master and pulled to 1.9 [08:00:09] The starting point for 1.9 will be whatever is on master in about three weeks [08:00:40] I'm wondering: Why not call it 1.10 right away, and do prereleases instead of 1.9.x ones? [08:01:12] calling it 1.10 sends the signal that it is ready for production use. 1.9 releases will not be at first [08:01:51] 1.10.0preX doesn't signal production use [08:02:09] I assume jeff is assuming that there will be too many releases for regular preX releases [08:02:22] pre1 doesn't work on windows for example [08:02:23] or that it indicates that 1.10 is imminent when it's not [08:02:42] yes [08:03:28] Folks are very used to 1.7.x being production ready for Windows. [08:03:47] that was more out of there not being a choice. [08:04:32] 1.6. with the smb redirector gateway simply didn't work on Win7 and above [08:04:48] Of course it's really up to you. Just wanted to provide input. [08:05:30] I should have cut 1.8 when we stopped creating 1.6 installers for windows but there are couple of things I've wanted to include in 1.8 that simply never got done. [08:06:21] The way I view the early 1.7 releases was if you were running Windows 7 the choice was "use 1.7.1 or don't use AFS" [08:07:12] The end of the year was a difficult time last year. [08:07:12] Do we have anything else for today? [08:07:38] Chances are very little would happen to 1.9 before January. [08:08:19] YFS shuts down over Christmas to New Years. Its one of the best opportunities for me to work on OpenAFS [08:08:45] Ah, fine. That's different this time then. [08:08:57] No, I don't have anything else. Anyone? [08:09:18] no (and I've got to leave, even if there is anything) [08:09:27] --- deason has left [08:09:31] Thanks everyone! [08:09:51] --- meffie has left [08:17:37] --- wiesand has left [08:17:51] --- Marc Dionne has left [08:22:01] --- ktdreyer has become available [08:33:12] --- Jeffrey Altman has left: Disconnected [08:38:34] --- Jeffrey Altman has become available [10:38:35] --- deason has become available [16:18:21] --- deason has left