[00:05:45] --- manfred furuholmen has left [00:07:07] --- manfred furuholmen has become available [00:22:53] --- dev-zero@jabber.org has left [01:15:26] --- dev-zero@jabber.org has become available [03:14:12] --- dev-zero@jabber.org has left [03:41:40] --- SecureEndpoints has left: Replaced by new connection [03:59:54] --- dev-zero@jabber.org has become available [04:27:04] --- SecureEndpoints has become available [05:15:07] --- manfred furuholmen has left [05:27:13] --- manfred furuholmen has become available [06:39:15] --- reuteras has left [07:13:19] a drum i should start beating now: regardless of whether i think we are at the point of needing regular meetings yet for 1.6, we do need one for establishing the path forward, whether that's dafs or not, and what pieces of rxosd can reasonably be integrated. crazy/sane/hate me? [07:14:15] Not crazy. Don't hate you. Not sure if that implies sanity or not. [07:14:42] The problem, as I see it, is that the community doesn't really have the ability to assess where we are with demand-attach. [07:15:19] Most of the bugs aren't public, and nobody's commented publicly about whether they're prepared to work on resolving the current issues. [07:15:40] while i agree with that (and with the discussion which happened earlier) i don't think that is necessarily even a large part of what we need to discuss [07:15:43] wrt dafs bugs.. [07:15:56] I have 50% of the approval needed to make things public..still working on the other 50%. [07:16:18] I expect that other 50% by Tues; next Thurs at the absolute latest. [07:16:33] There's not going to be a problem with that. [07:17:09] I think we should have a discussion about what we think the feature set for 1.6 should be, and what timescale we'd like to see 1.6 in. [07:17:11] I don't anticipate any problems with it -- the 'hard' 50% is done. The other 50% is just busy at the moment. [07:17:12] given that no one is currently using what's there in production, i think the issues are actually "given what you (community) know now are you going to feel confident deploying this near-term, or should we just stabilize without, get it out, and then come back to it? and if the answer to that is the latter, i think we can reasonably pull in much of rxosd and shipit in 1.6, for the simple reason that for sites not using osd, that stuff won't touch them [07:18:04] What is 'it' in that first paragraph? DAFS, or other 1.5 stuff? [07:18:11] dafs [07:18:18] sorry [07:18:43] it's like negative something fahrenheit and i have already been out in it including an adventure trying to get the car running [07:18:51] yeah, here too [07:19:04] Okay, so here's a meta point? Is our goal to have 1.6 stable this year? [07:19:07] i now understand why the lady from detroit had an engine block heater in it. sadly i don't park where i can use it [07:19:08] --- abo has left [07:19:22] --- abo has become available [07:19:22] I would like to see that goal achieved. [07:19:28] we've been talking about 1.6 long enough that i feel it would be irresponsible not to [07:19:29] (simon) [07:20:08] Okay, so can we ship a 1.6 that has demand attach, that we'd be happy describing as stable, within that time frame? [07:20:27] well, that's the discussion i want to have [07:20:40] at this point i think that answer is "no" [07:20:44] I'd agree. [07:20:54] To what do you agree? [07:21:07] That dafs cannot be stable in the current year? [07:21:14] That we can't do a credible stable 1.6 with demand attach this year. [07:21:15] --- mcohan has left [07:21:26] --- mcohan has become available [07:21:35] That seems to be a strong claim, working from available data. [07:21:45] Not that demand attach cannot be stable - I don't have the data to judge that. But, that we don't have the time to produce something that the community would regard as stable. [07:21:45] I'd estimate a stable DAFS by end of Q1, Q2 at the latest. [07:22:16] simon - right. there is a difference between 'something stable' vs 'something stable for community' [07:22:47] Yes. And there's a matter of shipping something that's actually had the kind of widespread testing that I'd like to see for these kinds of major jumps. [07:22:51] * stevenjenkins nods. [07:23:03] isn't there also a distinction between stable for the community with DAFS integrated, and stable for the community with DAFS configured? [07:23:40] part of the issue is that DAFS development is done essentially off the 1.4 branch, not 1.5 (although patches get cut to be applied to 1.5 as well). So for me, I'm unsure what else is in 1.5 that would impact DAFS stability (and stability in general). [07:23:54] Yes. I think there's a question about whether 1.6 ships with experimental features there, but #ifdef'd out. I don't have a strong feeling for that, beyond believing that matrix testing is hard. [07:25:06] In order to credibly produce 1.6, we need to produce a precursor that the community can meaningfully test, and to have that precursor available for long enough that we can iterate over that for a few cycles. [07:25:23] clearly, yes [07:25:55] To release this year, I think that precursor has to be available in the next 3 months. [07:25:58] question: has anyone tested 1.5 with dafs configured out? [07:26:03] Yes. It's broken. [07:26:19] can you be more specific? [07:26:19] I would say that should be the highest community facing priority for DAFS. [07:26:22] fixing that [07:26:58] Ask edgester - he was looking at it. I think volume creation breaks. [07:27:33] will do. [07:28:05] Another question ... If we pull dafs from 1.6, what else is there _that's ready_ that people are clammoring for? [07:28:52] fwiw, rx osd isn't ready, although there are a handful of 'goodies' that are probably fine. [07:29:13] end of Q1 is kind of late if we expect to be able to have 1.6 by say july. maybe we don't. i'd like to have 1.6 out for people who are academic to be able to deploy before fall. maybe that's unrealistic [07:29:41] > So for me, I'm unsure what else is in 1.5 that would impact DAFS stability (and stability in general). very little. [07:30:12] shadow - tx for the info. [07:30:12] it's broken: you create a volume and it immediately needs to be salvaged [07:30:25] > fwiw, rx osd isn't ready [07:30:27] even w/o DAFS? [07:30:45] to ship enabled. i suspect even beyond goodies certain parts can be integrated, turned off [07:30:52] that is the with DAFS behavior, certainly [07:30:52] --- abo has left [07:30:56] --- mcohan has left [07:30:57] even w/o dafs [07:31:24] the bug jason edgecombe had was without --enable-demand-attach-fs [07:31:26] tx for the clarification. [07:31:28] or whatever the switch is [07:31:50] --- abo has become available [07:31:57] --- mcohan has become available [07:32:28] I'm building 1.5 now and will look at that. [07:32:34] ok. thank you. [07:32:44] ie, w/o enabling DAFS. [07:32:44] Can we target bugs in RT? [07:32:53] yes, an RT number would be great here.. [07:32:57] Could we start tracking these kinds of things as 'must be fixed for 1.6' [07:33:14] yes - that would be my preference as well. [07:33:58] going to rt, hang on [07:34:23] I was thinking of the way that bugzilla lets you target bugs at particular milestones. [07:34:47] It would be good to be able to do a search for everything that's outstanding for 1.6 - that way there's a list that we can hopefully drive down. [07:35:02] --- manfred furuholmen has left [07:36:06] a properly configured bugzilla is less horrid to interact with than i am miserable about touching, the question would be who/how to get one configured. i would work with one if so [07:36:24] dumping content from RT into one would not be horrible if we didn't dump all tickets into it [07:36:44] the question then would be whether we still needed RT going forward. i have no answer and not necessarily any opinion [07:37:37] suggestion: create a '1.6 prequisites' ticket in RT, then simply link other RT's to that. [07:37:53] --- manfred furuholmen has become available [07:38:01] on the plus side, the greatly reduced amount of spam making it to RT's "inbox" has meant i've heard no more of the bogus "oh we assumed you weren't using rt anymore". [07:38:04] that's much less hassle than changing bug tracking systems (not that I have anything at all against bugzilla) [07:38:20] steven: yeah, i've used that before and am not averse to doing it that way iether [07:38:34] I think a tools debate is probably something to have after a release cycle, rather than in the middle of one :) [07:38:41] simon - exactly. [07:38:51] no argument [07:39:10] if someone wanted to do all the work for us and weren't otherwise useful, i wouldn't scream if they did it now [07:39:34] I'm interested in shadow's early comment, about targetting 1.6 for the summer, so sites could adopt it for the autumn semester. [07:40:18] That seems to half our available time (end of year vs middle of year), and probably guarantees that dafs wouldn't make the cut. [07:40:21] I think trying to target a 1.6 that has DAFS integrated, but not enabled by default *should* be reasonable. w/in that timeframe. [07:40:33] --- manfred furuholmen has left [07:40:49] ie, that takes a lot of the DAFS bugs out of the critical path for the initial 1.6 release. [07:40:59] but forces a cleaner integration. [07:41:08] I wonder if it's worth it though. How many places would deploy 1.6.0 over the summer if it only appeared in, say, May. [07:41:24] maybe worth asking on openafs-info [07:41:26] there are also tickets in RT (one from jweiss) regarding an inability to mix 1.4.x and 1.5.x file/vlservers in the same cell [07:41:51] actually, it may remove a lot of bugs, but it doesn't make testing any easier, because src/vol is effectively a new package in any DAFS-enhanced codebase, reagrdless of whether DAFS is enabled [07:41:51] --- abo has left [07:41:58] --- mcohan has left [07:42:29] --- manfred furuholmen has become available [07:42:34] --- abo has become available [07:42:40] if 1.6 is released in the Summer, the earliest I would expect to see it deployed in any cell of significant size is December [07:42:45] --- mcohan has become available [07:43:22] that's only because cells like andrew don't have rogue admins like me anymore [07:43:41] :) [07:44:05] So, should we be trying to release 1.6 from the 1.5 branch? Or should 1.6 be 1.4 + screened deltas? [07:44:16] you can perform a rxdebug -ver against the cellservdb cells and get a very good idea of what people are running. in most cases it is several releases behind [07:44:44] checking only vldbs is uninteresting. you really want the swede's cell-crash, i mean, census, tools [07:44:54] the only way to build off 1.4 for 1.6 is to decide that you want Windows to have its own stable branch [07:45:00] rerolling deltas on top of 1.4 may be massive pain [07:45:09] I didn't say check the vldbs [07:45:14] on the other hand i suspect unrolling dafs would not be that hard. [07:45:32] at the very least it is confined to a smaller portion of the tree [07:45:43] --- dmontuori has become available [07:45:55] src/viced, src/vol, effectively. and i can quantify all those deltas. [07:46:11] shadow - would a dafs unroll also unroll the vol pkg changes? (in my mind, those two are inseparable..but I'm often wrong..) [07:46:17] it would [07:46:28] because really, most of dafs *is* those changes [07:46:32] right. [07:47:00] And what of interest is in 1.5, and ready, if we unrolled dafs? [07:47:08] and some of the current bugs are hard to distinguish between 'vol pkgs' vs 'dafs-feature-per-se' [07:47:39] whether disconnected will be is arguable, you're perhaps in the best position to tell us [07:47:47] the 2 different stable trees problem dies [07:47:50] It's not ready as is. [07:48:01] Whether it will be ready depends on your timeframes. [07:48:14] most of the rest are features of ... well, not high visibility or wide applicability. [07:48:28] from my perspective getting the current windows releases on stable and off the dev branch would be a big win [07:48:32] so the main point would be a unified stable release? (ie, unix + windows) [07:48:36] --- abo has left [07:48:41] jeff, i agree [07:48:49] it would probably be the main benefit [07:48:50] --- abo has become available [07:48:53] in my mind not the main point [07:48:57] and all of the improvements in 1.5 related to prototyping, bug stomping, etc [07:49:03] IMO that seems enough of a win. [07:49:14] well, we've done a best effort on making all bugfixes hit 1.4 [07:49:18] It's a win for us, it's not really a win for the users. [07:49:26] but it's hard to say without all the prototyping, etc, that that is *true* [07:49:36] and if some dates can be establish, that lets other features like DAFS, disconnected, etc see if they can get stable to be included. [07:49:37] "Upgrade to 1.6, where everything looks the same" [07:49:37] --- mcohan has left [07:49:56] I think we need to decide whether we want to be date driven, and hit this year. [07:49:57] well, you have 2 camps [07:50:04] Or feature driven, and possibly slip to next. [07:50:07] --- abo has left [07:50:12] --- mcohan has become available [07:50:16] the latest greatest camp, which will upgrade no matter what, stable or unstable, and get confused at unstable [07:50:25] (It also depends on whether 1.6.0 is 'stable') [07:50:47] and the never upgrade ever camp, who will upgrade a month after complaining that their bug isn't getting fixed in the previous stable series because the code doesn't even look like that anymore [07:51:13] I think, no matter what, we should aim to have branched this year - so HEAD, or 1.7, or whatver is there for disruptive changes. [07:51:23] Tom has been giving talks at workshops for three years now on dafs. The gatekeepers have said for two years now that DAFS would be in 1.6. We need to take that into consideration. [07:51:25] i argue we can be date driven, get things sane and in sync, and then be feature driven starting on a new branch immediately after [07:51:38] date driven seems reasonable to me. [07:51:50] Personally, I'd be happy to hold 1.6 for dafs. [07:52:09] SecureEndpoints: ++ [07:52:10] But I can see all of the reasons for not doing so, as well. [07:52:16] well, we could cheat, release 1.8 without openafs, and then later release one 1.6 with dafs and immediately go to 2.0, thus not lying :) [07:52:29] I think people might see through that ruse. [07:52:31] er, 1.8 without dafs [07:52:41] sure. but as a literalist, ... [07:52:44] secureendpoints - good point. I had not taken that into consideration. [07:52:52] How big an incentive for those contributing to dafs would a line in the sand be? [07:53:15] that feels like it would light a fire [07:53:17] tom is probably asleep, and i am unsure steven has 100% of the data to answer that? [07:53:21] I've watched one open source project drive itself into the ground by attempting to be date driven for no other reason than to prove they could have a new version number on such and such a date [07:53:22] good question. I think getting the bugs exposed into RT will be good. [07:53:37] tom is on the road at the moment. [07:53:49] New releases need to be compelling. Otherwise, it isn't worth the effort of orgs to put their resources into testing [07:53:49] ah, going home from va i guess? [07:53:53] I do not have all the information to answer that.. [07:53:55] yes. [07:54:08] I think I'd like to see a realistic timescale for a 1.6 with dafs. [07:54:19] --- abo has become available [07:54:30] But, with the option of dropping dafs should it be the thing that's holding everything back beyond that. [07:54:33] then perhaps we should wait for tom, steven or someone to be able to provide it and just defer talk of 1.6 directly [07:54:51] I can certainly take the question to tom, et al. [07:54:54] now, that said, i have one other strawman to put out [07:55:02] s/can/will/ [07:55:12] ignore current release branches for the moment [07:55:30] (since this discussion is very similar to one we had earlier with tom, in a sense you already have) [07:55:54] assume i were able to merge the changes from 1.5.x in the library, client, and windows spaces with 1.4's servers. [07:56:04] (i am pretty sure i can; i have done it before) [07:56:39] would there be value in releasing stable releases for all OSes from that branch, and continue a development branch? ignore version numbering issue for now [07:57:16] also ignore cvs management issues as i suspect max will help us put that to rest very shortly; he graciously picked up the remaining stuff and is dealing [07:57:24] it's an integration base for rxosd [07:57:32] which it [07:57:44] --- abo has left [07:57:47] yeah, max said he'll have the most recent deltas done today. [07:57:56] --- mcohan has left [07:58:01] this seems like the wrong day to wear cropped pants and socks that do not reach them [07:58:03] er, mix [07:58:10] --- abo has become available [07:58:35] I think there's potentially value in that, in particular if a 'real' release is some time off. I suspect it would still need a reasonable amount of testing, as we'd be running all of the servers with some pretty substantial changes to the RX layer. [07:58:37] --- mcohan has become available [07:58:58] matt - some of 'the goodies' from rx osd should integrate ok, but rx osd itself has changes that will need discussion (e.g., steals bits from uniquifiers, extends vnodes, etc) [07:59:12] yes, indeed [07:59:13] actually, i argue that the changes in 1.5.x Rx are not very substantial at all, at the compiled code level [07:59:20] and DAFS + Rx OSD is a completely different animal.. [07:59:24] Okay, I'll take that point. [07:59:27] > and DAFS + Rx OSD is a completely different animal.. [07:59:32] i live in fear of that animal [07:59:41] * stevenjenkins does as well. [08:00:13] but we're working on that.. [08:00:15] --- dmontuori has left [08:00:21] --- dmontuori has become available [08:01:04] --- abo has left [08:01:11] --- abo has become available [08:01:19] --- dmontuori has left [08:01:33] In response to Matt's point, I suspect we're going to have the problem that whatever we do, the code is going to shift under rxosd, and there are going to be merge issues. [08:01:47] yes [08:01:49] There would seem to be real benefits in realigning the 'stable' trees again, though. [08:01:50] agreed. [08:01:58] also yes [08:02:04] yes [08:02:46] If we're going to take the effort to do that though, I think we should come up with a plan for how we avoid the split happening again. [08:03:02] wrt rx osd, it will take me some time to sift through the various pieces and come up with the list of 'what is problematic'. By that time, I'm hopeful we'll know one way or another wrt DAFS, so we can clarify the actual integration point for Rx OSD. [08:04:11] simon - can you expand on that? what 'splist' are you wanting to prevent? [08:04:14] err, 'split' [08:04:27] well, i think avoiding the split is easy as long as your release branch committers are well-coordinated and conversant in the tools [08:04:43] windows/unix stable split i assume [08:05:01] the primary reason the split occurred the first two times is that development of the Windows client surpasses the rate of change in the rest of the code base. part of that is driven by new operating system versions that required new support, some of it in dramatic changes in the feature set, and some driven by the need to respond in a timely manner to error reports. [08:05:07] yes, windows/unix stable [08:05:10] Yes - where we have an operating system whose stable releases are off the development branch. It seems like the major win from this proposal is getting everything on one branch again. [08:05:17] ah, ok. tx. [08:05:26] ... and it would be a shame to do all that work, and have things split again. [08:05:32] * stevenjenkins nods. [08:05:43] you left out another point, jeff. we had too many gatekeepers and were not on the same page. so for instance some unix changes were simply not making it to 1.5.x and needed to be resync'd later. [08:06:02] secureendpoints - do you think by mid-year that the rate of change on Windows will be closer to that of Unix? ie, more realistic to keep them in sync? [08:06:07] which caused a cascading failure [08:06:08] no [08:06:17] um, coordinating gk activity is not the same as having too many [08:06:43] i didn't say it was [08:06:45] Let's not go there in the discussion ... [08:06:53] i said they were problems. i didn't say they were the same one [08:06:54] s/the/this/, but you get my poiint. [08:07:13] the rate of change in the windows specific parts of the tree are always going to have a very high rate of change because there is still so much that needs to be done to improve the end user experience [08:07:24] I don't think it's an issue of rate of change, it's an issue of the impact of those changes on the rest of the codebase. [08:07:37] however, the rate of change required in other parts of the code base to support windows has essentially come to a halt [08:07:52] --- abo has left [08:08:13] so basically you're saying you beleve src/winnt will still change a lot while the rest of src is at a level similar to the rest of the products? [08:08:15] I think Unix should be more prepared to take the hit when Windows needs to change things. I don't think that's too big a price to pay in return for getting our dev/stable branches back. [08:08:21] --- abo has become available [08:08:33] simon: I agree strongly with that [08:08:34] that might argue for a separation of the windows tree onto its own branch that can be managed in conjunction with the core branch [08:09:33] That seems likely to lead to greater divergence between windows and the rest of openafs, including arbitrary divergence that just inevitably creeps in [08:09:37] --- mcohan has left [08:09:38] I'd rather not see more branches, but I'm not the one who has to maintain them. [08:09:49] --- mcohan has become available [08:09:57] well, in the git world i think we could just pull in changes from many independent branches at release time, as long as each part of the tree had just one canonical branch? [08:10:04] I'm not referring to version branches. The new windows tree would not have any of the core code [08:10:24] hm, ok [08:10:56] Okay. So Windows actually becomes a different tree entirely, and you use externals to link them all together. [08:11:03] separate src/WINNT into a new tree and manage it separately. its releases with be similar to KFW. A core release version and a product version [08:11:07] that seems pretty complex to me. [08:11:08] You could do it, but I'm not sure that I see what the gain would be. [08:11:25] i don't see the point [08:11:46] you are correct that the interface boundary between it and the core libraries should be stable [08:11:57] and so that should be *doable*. i just don't see the point [08:12:21] the benefit is that we don't have to issue new stable releases for Unix simply because Windows changes something in the client interface and needs a new version number [08:12:48] we already wouldn't, if we just make a sensible policy about how we do release numbers [08:13:01] but you need new releases for Unix, whenever anything changes on any of those platforms? [08:13:19] we (probably i) proposed a way to deal with that too [08:13:23] I think this ties in to another point of Derrick's [08:13:24] that is what happens today because we have to publish a new source tarball [08:13:38] because we are stupid about how we number releases, imo [08:13:50] I think you should be able to have 1.4.x.y [08:13:51] we had the plan that was devised in Tulum and never implemented [08:13:57] yes! [08:14:06] Where y can be an operating system specific release. [08:14:09] or 1.4.yyyymmdd [08:14:19] or something finer-grained [08:14:19] Just because you do a y for Solaris, doesn't mean that everyone gets one. [08:14:29] yup [08:14:31] can't do .y on windows [08:14:45] we are limited to three part numbers there [08:15:00] the fourth part has special interpretation [08:15:03] But you could have 1.4.600001 ? [08:15:10] indeed, simon [08:15:32] each component is a 16-bit value [08:15:41] You'd need to think about the way you structured that number so you still got inequality matches... [08:16:10] But would the general gist work? [08:16:25] the way we do it today on windows is 1.5.56xx where xx is used whenever we have needed 'a', 'b', 'c' releases [08:16:47] the proposal from Tulum was we effectively issue a release a day [08:17:09] --- stevenjenkins has left [08:17:10] Okay, but those 'a', 'b' and 'c' releases, could be the y code point from the earlier example. [08:17:14] and we declare which builds from which days are stable on which platforms [08:17:18] I think a release a day is confusing for users. [08:17:27] you don't give them to users [08:17:33] It doesn't work for OpenLDAP (not the release a day, but their sliding 'stable' markers) [08:17:43] the web site is what users go to [08:17:50] --- mcohan has left [08:17:57] --- abo has left [08:17:59] You can't stop users from getting them. And we're not Linux, we can't expect others to do our QA and integration work for us. [08:18:16] --- abo has become available [08:18:26] what we did for Kermit was have a release page that listed every supported OS, architecture, and version combination and then specified what the most recent stable was and the one prior to that [08:18:36] --- mcohan has become available [08:19:39] we can't ensure that every OS especially ones that we don't use ourselves on a regular basis works as designed [08:19:40] i'm unsure about that model, but to be fair we can do more research/outreach into this topic if the idea is at least workable [08:19:48] I can see the value of that - but I just think a release a day would cause confusion. [08:19:58] you can do a release a week [08:20:06] a release every two weeks [08:20:10] it really doesn't matter [08:20:17] a release a day was perhaps extreme but it was based on the realities expected at the time, which i think are not quite the same as now [08:20:20] --- stevenjenkins has become available [08:20:27] I can completely see the value of a sub release field which we increment _when we need to make a release_ and which just gets built for the platforms that need the fixes in it. [08:20:49] But, as soon as you step back from a release a day, you're into a time-based release cycle, and all of the pain that causes. [08:20:49] that sounds like the concise way to describe the concept [08:20:52] well, in that vein, it suggests we never do a non-"a" release again? [08:21:07] first release is e.g. 1.6.0a [08:21:16] need to increment for one platform? 0b [08:21:16] Yes, or 1.6.0.0. [08:21:19] sure [08:21:25] Yup. [08:21:27] or hoever we need to represent it [08:21:39] istr macos has a similar issue to windows [08:21:45] (in the plists for the components) [08:22:02] I think you may be right. It certainly had issues with 'rc' and similar in the version string. [08:22:38] oh, once you had letters it's a nonstarter. there are 4 legit letters, like, b for beta, r for rc something like that? [08:26:15] TN1132 seems to suggest you've got 4 numbers to play with. [08:27:18] ok [08:27:33] we can certainly categorize each OS and have an answer. [08:28:05] Linux doesn't care. [08:28:30] the q is do things like solaris pkgs, hpux (depots?) aix packages... [08:28:32] And I'm pretty convinced that's true for all values of Linux, given the Linux kernel's release numbering scheme. [08:29:35] sure [08:31:59] But, once we can branch in a more lightweight fashion, this seems like a good way of handling changes which are required by particular OSes. [08:35:26] once we aren't tied to the current delta system, branches are much easier to make [08:36:03] It sounds like a good plan, regardless of how we get to a stable branch that can support it. [08:37:49] Did you have another straw man? [08:39:26] no, that's it [08:39:28] another hand grenade ? [08:39:50] i will try to find time this weekend to look at what's involved in 1.4/1.5 merge. maybe during the football game [08:40:02] (since really, football is a social thing for me, not something i really watch) [08:40:22] you can eat stuff, drink beer, type [08:40:29] yes. [08:40:46] --- abo has left [08:41:06] last week i needed a break so i worked on cleaning up and OCRing historic documents during the game: http://picasaweb.google.com/shadow/AlleghenySouthSideRailwayDocuments# [08:41:28] --- abo has become available [08:42:21] stevenjenkins: Do you think you will be able to get an answer about dafs timescales? And, when you get it, would you be able to give an indication of how reliable that answer is? [08:42:48] simon - I've sent an email for the relevant people to look over the logs of this conversation. [08:43:20] Cool. Thanks! [08:43:24] I'd guess that later next week we might at least have some feel for things. [08:43:36] yw. [08:48:57] --- shadow@gmail.com/owl274581A9 has left [08:56:29] --- Derrick Brashear has become available [08:59:01] i guesws chaskiel's office network died, or it took a power hit. sigh. [08:59:23] No more lily? [08:59:28] no more johnstown [08:59:31] i don't use lily [08:59:39] no more meredith either apparently [08:59:43] Ah. Well, lily's gone too. [08:59:51] but i can't tell if it's a router or no power [09:00:17] given a comment on zephyr just before i lost, it's probably power, since johnstown was on a ups, and esp wasn't and apparently went away first [09:02:32] not a power hit. [09:03:42] sphinx is still up, so it's not a power issue in Chaskiel's office. A traceroute from my office to meredith stops at pod-a-cyh, which suggests the cyert hall aggregator is unhappy. [09:04:38] can't ping johnstown from sphinx? [09:04:50] I haven't tried. [09:04:54] i did [09:05:02] 100% packet loss [09:13:47] --- Moose has become available [09:15:39] --- dmontuori has become available [09:39:25] --- shadow@gmail.com/owl72084742 has become available [09:43:05] --- mcohan has left [09:44:00] --- mcohan has become available [09:45:50] --- sxw has become available [09:55:07] --- dev-zero@jabber.org has left [10:06:13] --- Russ has become available [10:30:01] --- sxw has left [10:53:10] --- dev-zero@jabber.org has become available [10:55:13] --- manfred furuholmen has left [10:55:21] --- sxw has become available [11:13:43] --- Derrick Brashear has left [11:14:06] --- Derrick Brashear has become available [11:28:55] fwiw, I could not find that edgester had opened an RT ticket for the volume creation problem in 1.5, so I opened #124142 and cc'ed him. [11:30:29] you probably could have, you know,... asked him to open one? [11:30:45] I emailed him earlier in the day about it, and I cc'ed him on the new ticket. [11:31:04] as I had already gathered the debugging data, it was easy enough for me to open the tix. [11:31:13] ok. [11:54:54] Lock hierarchies are dull. Just thought I'd share my pain. [11:55:12] we could do something like jaltman did in the windows client for lock order enforcement/verification [11:55:28] I looked at that, and thought it would be nice. [11:55:28] it doesn't help when you, um, miss the lock entirely and it doesn't help with OS locks [11:55:34] which is why i haven't bothered yet [11:55:44] At the moment, I'm working through disconnected and trying to tidy up the locking there. [11:58:09] What's the difference between MObtainWriteLock and ObtainWriteLock() ? [11:59:30] nothing. [12:00:10] we should just put the M versions to rest. [12:00:37] they were from when rx also used locks like that iirc [12:01:37] Ah. Okay. Thanks. [12:13:55] a question on 1.5 building from CVS -- if there are problems building, should I touch base here first, or go ahead to openafs-devel? [12:14:33] you can certainly ask here first [12:14:36] I'd ask here first [12:15:00] ok.. ./configure --with-krb5-conf=blah-blah, fails with: cmd.c:(.text+0xcb): undefined reference to `AssertionFailed' [12:15:15] ./configure, but no --with-krb5-conf, builds w/no problems. [12:15:30] (this is on Ubuntu, as well as RHEL 5) [12:16:45] that's.... not 100% helpful. more context? [12:16:48] that comes from lib/libcmd.a [12:17:03] I'll pastebin rather than spam here, one sec. [12:17:05] yes, i got that [12:18:01] i assume somehow the difference is our assert.h or not. but it's not obvious why, unless a dependancy order changes somehow [12:18:02] http://pastebin.com/d1a9e435e [12:18:17] another oddity is that it's trying to build klog, in addition to aklog, etc. [12:18:18] did you build from "make clean"'d state in both cases? [12:18:27] that's not particularly odd, no [12:18:33] make distclean && ./regen && ./configure... is my normal process. [12:18:50] for kicks, edit makefile and put libafsutil after libcmd? [12:18:59] I can do another make clean for fun, though. [12:19:03] ok; I'll try that first. [12:19:12] which makefile? klog's? [12:19:13] don't bother make clean [12:19:27] the one make filed in [12:19:47] "failed" in [12:20:28] oh god. sure. that makefile has its own set of libraries for god knows why [12:20:30] worked like a charm.. [12:20:55] klog's rule needs to not... do what it's doing. i'll figure it out [12:21:06] like, i know how to do it but i need to figure out which way is right. [12:21:18] * stevenjenkins nods. [12:21:19] appending cmd and rx onto the end = shoot someone [12:21:28] tx for the help. [12:28:19] --- Derrick Brashear has left [12:30:39] --- mcohan has left [12:34:47] --- Derrick Brashear has become available [12:37:59] --- mcohan has become available [12:49:27] --- Derrick Brashear has left [12:49:52] --- Derrick Brashear has become available [12:53:53] --- Derrick Brashear has left [12:54:23] --- Derrick Brashear has become available [13:05:52] --- sxw has left [13:24:41] --- sxw has become available [13:34:49] --- dragos.tatulea has become available [13:35:47] hi [13:35:55] hi dragos [13:36:04] hi dragos. Happy New Year! [13:36:19] Happy new year to you all! [13:37:48] How are things with you? [13:38:11] All well. [13:38:34] I was catching on the mailing list and thought I'd drop by. [13:38:59] And say hi. [13:39:18] lots of people want to use disconnected mode [13:39:36] really? [13:39:42] yes [13:39:45] hell yes [13:39:56] Oh yes, indeed yes. [13:40:01] yes [13:40:01] we need to figure out some way to get you to the workshop in June [13:40:04] Wish I had more time. MAYBE THIS weekend I will do something about pinning. [13:40:36] --- mcohan has left [13:40:48] I'm going through the existing code and doing some tidying. If you've got time, it would be great if you could look over that patch. [13:40:59] I need a context switch from work. [13:41:12] I know that feeling :( [13:41:29] --- mcohan has become available [13:41:35] I know that feeling. Everything blurs into one for me. Work says I should spend _some_ time on AFS, but I end up spending way too much ... [13:41:44] sxw: Please send it. I will look into it tomorrow. [13:42:27] yeah, tomorrow will be a good day for science, hopefully :) [13:42:40] dragos: doubt it'll be done by tomorrow, unfortunately. [13:42:41] sxw: Will you be around to discuss it? [13:42:49] well, send it anyway [13:43:04] I _could_ however send you the patch to fix extending in a truncate [13:43:26] Send it over! [13:43:30] --- abo has left [13:44:03] --- abo has become available [13:44:45] /afs/inf.ed.ac.uk/user/s/sxw/Public/openafs-disconnected-extend.patch [13:45:03] thanks [13:45:38] Will you be around tomorrow? [13:45:44] morning [13:45:57] Not during the day, no. I'm in rehearsals tomorrow, and there's a run tomorrow morning. [13:48:26] oh [13:49:14] One of the not-so-fun things about intensively testing disconnected mode is that its finding other bugs in the Linux CM, which haven't come to light previously because we've never been able to do operations fast enough. [13:49:43] How are you doing the intensive testing? [13:49:51] fsx? [13:49:57] um, that sounds like the microsoft cifs redirector bugs that have been found because of openafs cache manager [13:50:01] fsx was the first one. [13:50:08] Is it the testing framework developed by Jason? [13:50:25]