[08:08:33] --- Jeffrey Altman has become available [08:13:15] --- shadow@gmail.com/owl8EEDA0A2 has become available [09:03:29] --- Simon Wilkinson has become available [09:03:38] Right place? [09:07:37] Wrong time [09:14:09] --- jhutz@jis.mit.edu/owl has become available [09:28:55] --- mdionne has become available [09:36:49] at the top of the hour [09:37:27] Yeah. BST != UTC [09:38:37] 22 minutes [09:38:59] --- haba has become available [09:39:20] --- meffie has become available [09:39:26] OK; can we stop reporting every 2 minutes when the meeting will be? [09:40:13] ok. next update in 3 minutes then [09:43:28] While waiting, we can play the following video: /afs/stacken.kth.se/home/haba/pict/own/2010/06/22/mov01856.3gp ;-) [09:44:05] hey, i thought it was midsommer! (except i mocked you for your link which said it wasn't) [09:45:39] The midsummer business is an interresting one. Physically it IS midsummer (the shortest night etc etc) but I had forgotten that in Sweden the midsummer is moved to the friday AFTER because otherwise noone would work for the whole week. [09:47:01] So it's just another artificial festival? [09:47:08] However, the evening sun is shining and I should go out and have a cool beer in the sun instead. ;-) [09:47:32] It's just moved 2 days. [09:47:38] Same here. However, I will wait until after the meeting. [09:47:45] I do get the friday off [09:47:53] sun's out here. i am having a beer inside while the new iphone sets up [09:48:29] --- Russ has become available [09:48:30] You got an iPhone 4? [09:49:33] yessir. [09:49:41] Eh Simon, we now got a Cray in the computer room. Do you have any contact with someone who is already running such a beast? I will not be main responsible, but I expect that we want AFS clients sooner (rather) or later. [09:50:25] I don't, no. [09:50:49] What do Crays use for their front end these days? [09:51:17] The whole thing runs a stranegely hacked version of SuSE [09:51:42] --- Derrick Brashear has become available [09:52:18] --- cg2v has become available [09:52:52] does anyone need me to generate a current ChangeLog? i assume yinz are basically familiar with what's in the tree or won't have time to read it all anyway if you're not [09:53:37] Yeah. I think a ChangeLog against the 1.4 branch point is just going to be insane. [09:54:53] * cg2v wonders how much openafs-devel he can skim in 10 minutes [09:55:37] i bet the loudest part of what you skip is the --enable-fast-restart discussion [09:56:22] Yeah. There's scarier changes than that :) [09:56:41] i agree. but most of it wasn't loudly discussed [09:56:53] --- tkeiser has become available [09:56:54] Simon: One of the other few Crays in Europe is at the EPCC, that's why I was asking. [09:58:05] They don't run AFS, sadly. I think they've just started trialling NFSv4, the poor souls. [09:58:18] --- meffie has left [09:58:40] --- deason has become available [09:59:05] --- meffie has become available [09:59:44] The Cray runs NFS internally because some can boot diskless without NFS, some can't [10:00:14] Seems that we would be the first ones to try. Hm. This will be fun.... [10:00:30] > we now got a Cray in the computer room. maybe you want to talk to moose? or maybe kenh; I can't remember if they had one [10:01:38] (and I would not be sad if I would find a reason to say hello to you Simon) [10:02:06] ok. well. i wonder what the odds are everyone who is coming is here [10:02:15] since, well, we're on. [10:02:46] tjhsst has or a had a cray, but it may be so old as to not be useful [10:02:56] Are you expecting anyone else? [10:03:13] probably not [10:03:18] (cray sv1, I think? I know nothing about them, so I don't know how useless that is) [10:03:28] You never expect the spanish ... just begin ;-) [10:03:39] Shall we begin then. Hazel's home and we have dinner plans ... [10:03:42] so i guess we should start with where we are: it's not really controversial, since, well, it just is [10:04:00] --- tkeiser has left [10:04:11] at this point we have what seems to be stable dafs. i (and probably others) are still testing [10:04:11] Can I suggest that someone open RT tickets for everything that we decide needs doing before 1.6? [10:04:15] --- tkeiser has become available [10:04:28] That sounds like a great idea. [10:04:29] sure. we can tie them all to a single ticket to make it obvious [10:04:35] (a dependency ticket) [10:05:12] We have the technology [10:05:43] we have considerable updates since 1.4 in many spaces, especially thanks to warning killing, so even if you don't use new features, and even if you're not touching the fileserver, there's been a lot of code touched [10:05:50] things which i believe today to be issues: [10:06:02] 1) weak testing of sys5ish platforms: aix, hpux, irix [10:06:40] > we have what seems to be stable dafs by what metric? what do we have in the way of tests or something? it would be nice to be able to generate confidence that it's correct, rather than just a lot of "it hasn't broken for me yet" anecdotes. [10:06:50] 2) weak testing of non-dafs fileserver. well. i guess more "insufficiently broad" rather than weak. i have been running both ongoingly in real service in several environments [10:07:28] jeff, the tests (that i have) are still being rewritten so they can ship [10:07:36] they are not ready to be committed yet [10:07:49] i believe there are other tests but i can't volunteer anyone else's effort or code [10:07:53] you mean, the tests you did umpteen years ago for MS, or something else? [10:07:57] something else [10:08:14] and not just "it hasn't broken for me yet", but "it has been breaking much less than it used to", if that's something [10:08:17] when these tests appear they will be in openafs/tests/ [10:08:19] I don't believe that we need to be stable to branch 1.6 [10:08:47] Stanford University funded development of a test suite for demand attach, which is what Derrick is talking about. [10:08:50] sure. but my belief is we are anyway, which will help in getting further testing [10:09:12] Simon, I thought that was the definition of 1.6 [10:09:21] It's the definition of 1.6.0 [10:09:22] branching 1.6 != releasing 1.6 [10:09:22] We need to be stable to release 1.6. [10:09:23] branch 1.6, not release 1.6 [10:09:36] oh, yes, sure. [10:09:40] note that today we have no unstable branch [10:09:42] Stabilizing on a branch versus stabilizing on master is one of those long-standing procedural debates. [10:09:44] we have master, and we have 1.4 [10:09:45] We have to approach this as the start of a process, rather than it's completion. [10:09:52] Sorry, stray ' [10:10:03] yay, you caught yourself before i did:) [10:10:16] --- tkeiser has left [10:10:38] --- tkeiser has become available [10:10:41] so anyway, back to where i was [10:11:05] --- meffie has left [10:12:14] other platforms have been tested more completely, notably linux 2.6 and macos, and there has been more attention to solaris than any of the sys5y platforms have had [10:12:25] so, basically, the questions are [10:12:31] 1) what should go in before we branch [10:12:38] --- meffie has become available [10:12:38] 2) what if anything should come out before we branch [10:12:51] 3) when should we branch? (i think when 1 and 2 are done, but we should set a deadline) [10:13:44] likely candidates for 1 are in gerrit [10:13:55] however i believe we should provide one more: [10:14:02] And then ... what should go in before we release? [10:14:03] the equivalernt of fast-restart for dafs [10:14:22] Based on the discussion, if that's fairly easy to do and we can make it not a compile-time option, I'd like to do that. [10:14:27] well, i think we have to branch first, but yes, i guess we can talk about it now [10:14:42] I would like to see another 1.5 release before we branch. [10:14:45] russ: we can do a command line option. we should make it suitably named that people realize the risk [10:14:50] Since a ton of stuff has accumulated. [10:15:00] russ: agreed. i want 1.5.75, i needed to fix the rx mty thing for jeff [10:15:03] Yeah, I'm thinking of some sort of --destroy-my-data fileserver flag. [10:15:04] mtu [10:15:05] we can continue to issue 1.5 releases after the branch [10:15:30] Indeed. [10:15:31] Jeff: Yeah, but I think it's worthwhile to do a 1.5 release from master immediately before the branch since it then serves as a synchronization point. [10:15:31] i assume we will issue more 1.5 releases post-branching, from the 1.6 branch, until we are ready for RCs [10:16:05] Personally, I think we should consider moving to RCs immediately. [10:16:08] Then immediately after that release, we branch and change the version number on master to 1.9. [10:16:14] i'd like 1.5.75 before we issue any rc [10:16:18] Me too. [10:16:22] I take it from your earlier comments that the newer parallel salvaging stuff will not be going in? [10:16:25] That's fine. [10:16:36] But once we've branched, I think we should only cut RCs from the 1.6 branch. [10:16:45] deason: i'd prefer not, simply as it's a new batch of code to test [10:16:52] but i am but one voice there [10:17:01] after we branch 1.5.x and 1.6.RCs only from the branch, not master [10:17:01] I think the ship has sailed for big shiny newness on 1.5 [10:17:04] I want to test a 1.5.75 fileserver before the rc frency begins. But it would not need the whole binary stuff. [10:17:08] > the equivalernt of fast-restart for dafs what does that mean? [10:17:25] it means "don't assume anything needs a salvage even if shutdown was unclean" [10:17:32] if possible, I'd like to break out and submit some of the internal salvaging changes for 1.6.... [10:17:36] except this is safer as the demand salvage will still happen [10:17:42] deason: ok, that sounds reasonable [10:17:50] wrt dafs 1.6, there is another change we need to make before the release: fsstate.dat needs to record a copy of the capabilities bit vector and fileserver runtime options so that we can determine at startup whether or not to throw away callbacks... [10:17:51] to make some things possible, some things were done e.g. taking away global variables and putting them in a struct that's passed around [10:18:05] doing that in 1.6 will make pullups easier for e.g. salvaging changes [10:18:09] I think we need to think about freezing the 1.6 branch for a while. [10:18:18] Otherwise, the testing we get will be less than helpful. [10:18:19] tom: can you open an rt ticket for that? even just brief mail to -bugs [10:18:28] sure [10:18:31] So, have a period between branch and 1.6.0 in which only bug fixes make it in. [10:18:41] Absolutely no new features. Not even little ones. [10:18:41] simon: after 1.5.75 we can freeze for e.g. a week? [10:18:55] Agreed with Simon. [10:18:55] Well, I think we should freeze the branch for as long as it takes. [10:18:59] I suspect we'll need longer than a week. [10:19:05] well, gotta start somewhere [10:19:07] also, if the newer pthreaded ubik stuff is not going in, the ReadAnyWrite interface could be pulled [10:19:27] and if we get reports, fixing them is more helpful than asking people to test knowing they will report the same again and again [10:19:28] Once the first RC is issued, bug fixes only until the release. That really should be true for _every_ "stable" release. [10:19:37] andrew: nothing uses it, so it's harmless to stay [10:19:40] --- meffie has left [10:19:52] jhutz: I sympathise, but I'm not interested in that conversation right now. [10:19:53] --- meffie has become available [10:20:04] jhutz: it depends how you construe bug. also, ==sxw [10:20:13] Sure, we can fix bug reports. But nothing that isn't a bug fix. [10:20:16] At this point, pulling code is a risk even if no one calls it, and it doesn't fix a bug, so we can just leave it. [10:20:32] I'm a little uneasy about keeping an interface in the tree that is known to be broken, but... [10:20:40] fine, so let's limit the scope to the present release. [10:20:43] then add a comment! [10:20:49] add 2. they're cheap [10:20:56] can the interface be removed if it isn't used and put back after the branch ? [10:21:04] --- zuluchas has become available [10:21:07] we could do that [10:21:14] We can do 1.5.x's for a while, but once 1.6.0rc1 is cut, no non-bug-fixes on the 1.6 branch until 1.6.0 is cut [10:21:15] I'm with Russ with regards the risk thing. [10:21:38] Once the 1.6 branch is cut, no non-bug-fixes on that branch until 1.6.0 is cut. [10:21:39] in this case i don't think there's much risk. just roll back basically the most recent patch in the code [10:21:41] me too [10:21:42] --- zuluchas has left [10:22:01] jhutz: "me too" untargeted? not useful [10:22:02] and the interface in this particular case was just added... what, a week or two ago? [10:22:07] yeah [10:22:15] Okay, so maybe I'm more happy with rolling that back. [10:22:16] in this case i am comfortable pulling [10:22:20] perhaps not generally [10:22:24] Oh, okay. [10:22:31] > Once the 1.6 branch is cut, That's fine too, as far as I'm concerned. but then, why do any 1.5.x releases from the branch. "me too" with regard to the risk thing [10:22:36] For Windows, we also need to plan for runtime defaults changing once the 1.6 RCs have started. That will block future 1.5.x releases from the branch. [10:22:39] Yeah, not having people use it by mistake is a minor good, and if it's brand new and hasn't been in a 1.5 release, let's just pull it. [10:22:48] We can put back the fixed version after we branch. [10:22:50] I don't think we should do 1.5.x release from the 1.6 branch. That way lies insanity. [10:22:51] but ==russ (again), too [10:22:52] --- zuluchas has become available [10:23:05] --- haba has left [10:23:16] jeff: explain what runtime defaults you expect will change? [10:23:27] also: are you proposing you want 1.5 releases after 1.6 rcs start [10:23:32] Simon: We're going to be doing 1.7 releases from what's essentially a 1.8 branch going forward, though, aren't we? [10:23:49] I mean, 1.5 basically is alpha candidates for 1.6. To me, they're the same sequence. [10:24:09] russ: i agree, i want to confirm jeff agrees [10:24:09] We switch from 1.5.x to 1.6 RC when, well, we have RCs. [10:24:14] Well, I see it as master being a branch to which we apply unstable numbers, and each of the stable sequences as being branches from master. [10:24:32] so, we end up in a funny corner. suppose we release 1.5.75 (is that next?) and then branch 1.6 from that. ~nothing should then appear on the 1.6 branch that doesn't also appear on master, naturally, since that would get things out of sync. but people are going to want to keep doing development before 1.6.0 is released. Do we call those 1.5.x releases, even though they're from after teh 1.6.0 branch point? [10:24:58] i think we do [10:25:00] jhutz: As soon as we branch, master should become 1.9. [10:25:00] If you want people to test then 1.6.0rc1 is a much bigger incentive than 1.5.96, imo. [10:25:07] Simon: Agreed. [10:25:22] I don't think we should be doing development releases until 1.6.0 is out of the door. Lets focus our attention. [10:25:38] Yeah, but we should do the version number change on master anyway in case people build Git snapshots. [10:25:42] If 1.6.0 takes months, then we can reconsider that. [10:25:52] > master should become 1.9. so we release 1.9.1 or whatever before 1.6.0? I mean, releasing 1.9.x before any 1.7.x or 1.8.x is already going to be confusing enough. [10:26:01] If 1.6.RCs take three months (the 1.4.RCs took longer) then we will need a mechanism to continue issuing Windows releases. For Windows, since 1.5.x is production it was agreed that runtime defaults would not change nor would packaging changes be made until 1.6.RCs. Things that were discussed on the list were removal of afscreds.exe, afs_config.exe, modifications to the installer defaults, changing the defaults for some other settings. [10:26:04] No, I don't think we should release from master until after 1.6 is out. [10:26:04] simon wants to do versioning differently (with git tags). we can do that eventually. but it's not for today [10:26:07] I'm just saying change the version. [10:26:13] I'd quite like to land the change that means that builds from git snapshots so that development release don't have numbers. [10:26:18] --- haba has become available [10:26:20] Speaking of which, one of the things that I'd like -- ==Simon. [10:26:24] I want to get that in before we branch. [10:26:27] In some form or another. [10:26:41] jeff: then i will pose that if we need to we branch a "continuing 1.5 release series" from the 1.6 branch [10:26:47] and make windows releases there [10:26:48] ==derrick [10:26:51] with the old defaults [10:27:01] if we need it, and not if not [10:27:10] ==derrick. [10:27:12] And we should only build those releases for Windows. [10:27:13] Branches are cheap. [10:27:15] yes [10:27:20] (so no Mac, or unix builds from them) [10:27:28] Maintained branches aren't cheap, but this one should be cheap. [10:27:33] I think PR wise, we want to push everyone at 1.6.0rc being where they need to be. [10:27:39] a windows-only 1.5 branch would be cheap [10:27:46] Right. [10:27:49] when we think it is, yes [10:27:50] Simon: Agreed. [10:27:59] I agree with adding the RC to get people to test. [10:28:00] OK, what if we do two branches at basically the same time. One is the 1.6 branch, from which 1.6 RC's and 1.6.0 are released. The other is the 1.5 "stable" branch, used for doing further stable releases for Windows (and MacOS X?), but _not_ for new development. New development happens on master, with the next release being a 1.9.x, but (tentatively) not until after 1.6.0 is out. [10:28:16] Not Mac OS X. [10:28:19] But yes. [10:28:30] --- edgester has become available [10:28:31] jhutz: Agreed. I'd prefer not to release a 1.9.0 until we get 1.7.0 out, for that matter, but that may be too hard. [10:28:31] dammit, I take too long to type things [10:28:50] i'd prefer to defer the 1.5 continuing branch until the 1.6 branch becomes rcs [10:29:04] We can always make the branch whenever. [10:29:06] yes [10:29:12] Yeah. You can branch from any point in time. [10:29:13] I vote we make the branch at the point when we decide we have to make another 1.5 release. [10:29:16] but i'd prefer later to earlier [10:29:16] We might never need to. [10:29:20] yes [10:29:28] defer as long as possible [10:29:41] So, what do we need to do before we cut the 1.6 branch? [10:29:51] Get in some variation of Simon's versioning patch. [10:29:53] Release 1.5.75. [10:30:02] what in gerrit should go in [10:30:15] what do you branch from? It can't be the 1.6.0 branch, once the incompatible for-6.0 changes Jeff is talking about happen. And it shouldn't be master, once further development has happened, since continuing 1.5.x is not supposed to have new development. [10:30:16] andrew, what do you believe we need in terms of bugfixes from your pending changes? [10:30:18] we should cut a 1.5.x branch from the 1.6 branch prior to any Windows defaults or installation changes hit [10:30:26] I think we need to build both dafs and normal fileservers side by side. [10:30:30] jhutz: We would branch from 1.5.75 to make more Windows-only 1.5 releases. [10:30:38] jhutz: what jaltman said should be fine [10:30:44] or that [10:30:49] derrick: trying to look and read here at the same time, lemme see... [10:30:51] simon: in every build? [10:30:54] Yes [10:30:56] deason: understood [10:30:57] But note that we can cut a "continuing 1.5" branch from same branch point as the 1.6 branch, even if we actually _do_ it months later. [10:31:15] are we going to do something about the linktable collision thing rainer and I were arguing about? [10:31:16] rxgk, rxk5 are not in master, right? [10:31:19] I don't care where we cut the continuing 1.5 branch now. [10:31:21] jhutz: Correct. [10:31:26] 1903/1940 [10:31:33] --- meffie has left [10:31:33] --- tkeiser has left [10:31:35] deason: i [10:31:37] I don't mind if rainer's version goes in; it's better than nothing [10:31:39] Should the output table stuff in libcmd go in before the branch? [10:31:48] i'd prefer to do it right but we could take rainer's version [10:31:51] --- meffie has become available [10:31:52] Russ: I don't think so. There are no callers [10:31:56] --- tkeiser has become available [10:31:59] Shall we do this with a bit more structure? [10:32:10] simon: "this" [10:32:13] I'll paste in the summary of each gerrit change, and we can discuss [10:32:16] simon: there's a caller in another gerrit changeset [10:32:19] simon: ok [10:32:21] I thought [10:32:22] Works for me. [10:32:31] deason: Yeah, I think so too. [10:32:41] Windows: Cleanup of src/config/NTMakefile [10:32:44] --- matt has become available [10:32:44] > I think we need to build both dafs and normal fileservers side by side. Me too, unless we can figure out how to make it a runtime option. $prefix/libexec/fileserver needs to always be a non-dafs fileserver. Much better for it to not exist at all on a dafs-only build than for it to exist and be the wrong kind. [10:33:20] I think that one is a no-brainer. Anyone else? [10:33:34] yes, we take [10:33:34] Yup, in. [10:33:48] vos: Interpret VLOP_* lock flags [10:33:49] Russ: the output table stuff, i thought there were questions if that belongs in libcmd [10:33:53] In. [10:33:55] VLOP flags: in [10:33:56] meffie: There are. [10:34:06] Can we discuss in order? We'll get to libcmd. [10:34:08] I asked in part because I know it's controversial. But we'll get there. [10:34:21] for dafs vs non-dafs. Can the "fileserver" process accept a -dafs option that causes it to exec() dafs-fileserver? [10:34:31] jeff: wait [10:34:33] Only issue with VLOP is if it breaks things that parse command output. [10:34:34] VLOP: in, but assuming people are okay with that output format [10:34:46] well, it's only adding new lines, not changing any existing ones [10:34:46] But I think that's fine across a release boundary. [10:34:55] So, in as far as I'm concerned. [10:35:02] that output shouldn't break any reasonable parser [10:35:08] Well, it's okay across a release boundary as long as it doesn't break things badly, but that in particular should be fine. [10:35:11] also "it's locked". you already lost [10:35:13] VLOP flags: in [10:35:13] I say that as someone who parses vos output. [10:35:16] Cool. [10:35:17] windows don't include afsconfig.h and afs/param.h in util_cr.c [10:35:27] I think we're rejecting that one. [10:35:35] we are? does util_cr need them? [10:35:39] For assert. [10:35:43] This is fallout from a bigger change - that assert.h has gained dependencies due to my work with clang [10:35:51] the fix to util_cr.c will be required by 1.5.75 [10:35:52] it's a very early . ah. crap. [10:35:54] > I say that as someone who parses vos output. Me too [10:35:57] yes, i thought so [10:36:00] (required) [10:36:07] so util_cr needs to not assert [10:36:11] Oh, okay. [10:36:15] Marc has also pointed out that we need to fix the way Linux calls osi_Assert() [10:36:17] Then in, but not that version of the patch. [10:36:22] it does not. assert need to be removed. Matt and I are working on it [10:36:29] (because it requires osi_AssertFailK, which normally doesn't return to return) [10:36:38] I'll fire that at RT. [10:36:44] yes, so we don't assert. a different version. anyway, next [10:37:00] vldb_check: Interpret VLOP_* vlentry flags [10:37:03] in [10:37:03] In. [10:37:11] Don't hold on to the afs_xvcache lock while creating a symlink [10:37:15] in imo [10:37:23] after investigation it's right [10:37:27] In, I think, although the risk does scare me a little. [10:37:32] albeit with a better comment [10:37:32] vldb_check: in [10:37:36] We already have LocalHero races, though, so what's one more. [10:37:42] it shouldn't race. [10:37:49] either my rpc wins, or it loses [10:37:51] * Russ doesn't know the code well enough to have an opinion. [10:37:53] Sure. [10:37:59] --- tkeiser has left [10:38:00] if mine wins, i am localhero [10:38:01] In, I think, but we should keep an eye on it. [10:38:09] ok [10:38:13] --- tkeiser has become available [10:38:20] An RPC test dispatch library for vice [10:38:21] and rainer says there's another patch pending to remove a xvcache hold across GiveUpCallbacks, btw [10:38:32] any idea if that's in a 1.6-ish "soon" timeline? [10:38:34] rpc test: in [10:38:39] Cool. [10:38:49] there should be no local hero race if we take that [10:38:52] ==sxw The description sounds right, but I haven't reviewed the code. The fileserver certainly should be able to do atomicity [10:38:55] I'm not sure it matters whether the RPC test library makes it in or not, since I don't think the caller is going to make it in, but it's also fine. [10:39:08] russ: i'd like it as it will ease other testing [10:39:12] Then in. [10:39:18] --- haba has left [10:39:20] rpc test: nothing is calling it in tree, it's harmless either way [10:39:29] deason: I think any major changes that haven't made it into gerrit yet, are probably out for 1.6.0, unless we decide now that they're release blockers [10:39:33] in general, anything in /tests is fair gamre to change whenever [10:39:37] can we slow down just a tad [10:39:39] it's not part of the binary release. [10:39:43] ==derrick [10:39:49] --- meffie has left [10:39:50] jhutz: only if you promise not to make things drag on for hours [10:39:50] --- haba has become available [10:40:03] --- cg2v has left [10:40:11] tests is very new and is going to be in flux for a while, and should not be considered horribly stable at this point. I don't expect 1.6 to have a meaningful make check; that's for later. [10:40:13] Yeah; it'd be nice to have time to type up something before you've gone on to the next one. [10:40:23] type faster. i hunt and peck [10:40:24] --- meffie has become available [10:41:03] Okay if we move on? [10:41:09] fwiw, the next ones from me related to ubik/vlserver can be done as one chunk together; they're the same thing [10:41:20] It'd help a lot if people' messages weren't 1000 characters wide, so the window fits with my browser. [10:41:35] I have no opinion on RPC tests yet; I'm not entirely clear on what that change _is_ [10:41:41] Jaltman asked for NT build for rpc tests. I need an hour or two to test that [10:41:45] ... but I'm not asking to block while I figure it out :-) [10:41:49] ubik: Fix buffers for reading-during-writes and the rest of deason's ubik changes? [10:41:49] rpc tests: it's a test. you don't care [10:41:53] jhutz: Yeah, that's a client mismatch problem; not adding newlines makes them look better in other clients and is easier to type. [10:42:15] ubik changes: out, imo, unless he is distilling out needed patches [10:42:22] I'm a little scared of changing ubik in a way that seems rather fundamental this late in the game. [10:42:27] yes, ==russ [10:42:37] It is cool, but scary. [10:42:41] The change seems fine, but it seems like a 1.9 thing. [10:42:46] it will be cool for 1.9 too [10:42:51] yes, that's fine; I'm not pushing for 1.6 particularly fervently [10:43:13] Okay. Great. [10:43:14] should we discuss pulling the ReadAnyWrite interface at the same time, then? or... [10:43:24] Yeah, I think we should pull it for right now. [10:43:34] I'd agree that pulling it seems like a good plan. [10:43:38] Do you want to roll that patch? [10:43:51] ubik: sorry, but I agree with Russ and Derrick - some of those changes seem obviously OK, but others are scary [10:43:53] sure [10:43:58] should rt get a ticket? [10:44:05] yes, please. [10:44:16] that I will create? [10:44:16] --- Jeffrey Altman has left: Replaced by new connection [10:44:16] --- tkeiser has left [10:44:17] Shall I handle RT? [10:44:17] --- jaltman has become available [10:44:29] or simon; either way [10:44:31] Whoever's willing would be great. [10:44:51] ok [10:45:05] I find myself wanting gerrit to have a feature whereby I, as a reviewer, can batch a set of changes together and review them collectively. [10:45:08] --- tkeiser has become available [10:45:27] 127520 in RT. [10:45:29] Moving on ... [10:45:54] cache-bypass explicitly reference pages involved in background i/o [10:46:01] I think this is safe, and uncontroversial. [10:46:04] In. [10:46:05] if we agree it's right, in [10:46:16] ==shadow [10:46:19] Is this a good point to talk about cache-bypass in general? [10:46:26] --- meffie has left [10:46:35] should we do configure options after gerrit? [10:46:39] Yes. [10:46:41] Okay. [10:46:42] that's a good question. is cache-bypass in? if so, does it stay? [10:46:52] Moving on, then... [10:46:53] vol: break callbacks when needsCallback is set [10:46:56] jhutz: already in, will stay, q is on by default, moving on for now [10:47:07] i think that's in. [10:47:13] In. [10:47:27] --- meffie has become available [10:47:28] In, as far as I'm concerned. [10:47:37] and now it *is* in [10:47:37] in [10:47:38] > If we are not the fileserver, tell the fileserver over FSSYNC to break callbacks if we can. When can this happen? [10:47:38] --- haba has left [10:47:49] volserver [10:47:49] dafs, I assume. [10:48:18] --- haba has become available [10:48:19] preparing rxosd integration: change in AFSFetchStatus [10:48:38] out [10:48:41] Out, as far as I'm concerned. I still don't think we've resolved the protocol field hijacking issues. [10:48:43] I think that's work on a new feature, so out. [10:48:47] so, it seems that if the volserver attaches such a volume, maybe it should wait until _after_ it's done whatever to tell the fs to break the callbacks (and in fact, in the non-dafs case the FS will figure it out), to avoid unnecessary duplicate breaks? But anyway, in, modulo changes. [10:49:07] Provide manpage for fssync-debug and most subcmds [10:49:11] yes [10:49:16] In. [10:49:19] AFSFetchStatus: out, and don't reuse protocol fields [10:49:19] Yup. [10:49:23] should we take as-is or wait for him to incorportate feedback [10:49:25] I'm inclined to push that right now and we'll add the other subcommands later. [10:49:30] jhutz: stale. i said it in the ticket [10:49:30] I think that's a good plan. [10:49:39] russ: push [10:49:52] I need to review and check POD syntax, but will do that hopefully today. [10:50:04] > i said it in the ticket you're two or three changes ahead of me again, I don't know how, and I'm barely keeping up _without_ reading the comments. [10:50:12]