[00:03:52] --- dev-zero@jabber.org has left [00:40:02] --- dev-zero@jabber.org has become available [00:43:00] --- haba has become available [03:42:00] --- SecureEndpoints has left: Replaced by new connection [05:10:44] --- manfred furuholmen has become available [05:44:29] --- SecureEndpoints has become available [06:09:47] --- matt has become available [07:19:43] --- haba has left [07:20:56] --- haba has become available [07:27:55] --- reuteras has left [07:33:25] I just noticed that rxgen spits out k&r function headers, not ansi. simon, is that on your hit-list? [07:35:53] There's a switch which makes it do ANSI. [07:35:58] We use that switch everywhere, AFAIK. [07:36:49] ah, ok, great. didn't see the switch (and a 1.4-based build didn't use it, as it generated k&r -- but that build is 1.4.6 + some patches) [07:37:38] there is a good chance that no 1.4.x build uses it [07:37:43] I think we should do it in 1.4.x. But we've stopped targetting 1.4 with code cleanup patches, so it's possible that some directories there build ANSI, and others build K&R. [07:38:11] when we commit changes to 1.4.x we do not include code cleanup [07:38:27] ok. sounds good, and I won't worry about reporting 1.4 code cleanup issues. [07:38:35] If anyone has some time they're prepared to be bored for, I have a load more code cleanup patches that need reviewed. I just try to avoid swamping Derrick with them... [07:38:56] the idea is to keep the patch as small as possible so that those who want to examine the differences between the releases can very quickly understand how minor or major a change is and what it does. [07:39:32] And as 1.4 diverges more and more from 1.5 and HEAD, targetting code cleanup at all 3 branches gets very, very dull indeed. [07:39:36] the only changes that go against 1.4.x are operational bugs [07:40:14] not only dull but very error prone [07:41:21] the 1.4.x branch for example contains none of the 64-bit code cleanup done to permit builds on non-*nix 64-bit platforms [07:42:25] those changes included a large amount of prototyping (but not all that is necessary) along with a number of variable type consistency issues [07:42:42] --- abo has left [07:42:53] wow. I did not realize 1.4 had diverged so much. [07:43:02] The differences are pretty massive. [07:43:14] too big a change for 1.4 that is why Windows builds off of 1.5 [07:43:17] Even if you don't consider the major feature changes. [07:43:37] --- mcohan has left [07:43:40] --- abo has become available [07:43:42] my understanding was that the main difference is that 1.4 is *stable*, so unstable changes don't go in, but that things that were stable *do*. [07:43:49] --- mcohan has become available [07:44:01] stable means we do not make unnecessary changes [07:44:17] The problem is that we really don't know about the stability of things like disconnection AFS, and cache bypass. [07:44:58] stable means that we minimize the opportunity for error [07:45:10] secureendpoints - I can understand that view. I just interpreted 'stable' differently. Thanks for clarifying. [07:45:52] As far as I can see, 1.4 is dead for anything other than bug fixes. If you're building feature improvements on 1.4, you're going to have fun pulling them up to 1.5 [07:50:05] This may be an overstatement, but I'm very tentative about the sheer size of changes in 1.5 vs 1.4 for Unix. [07:50:25] it seems a huge jump to go from 1.4 to 1.5. [07:51:13] Well, the only real solution to that would be to release a 1.6 based on only some of the changes in 1.5. And that's a _huge_ amount of work. [07:51:31] * stevenjenkins nods. That's actually what I was thinking. [07:51:42] The problem is that the longer it takes DAFS to stabilise, the longer it's going to be until we can have 1.6, and the more changes there will be in 1.5. [07:51:45] ie, 1.6 is only a subset of 1.5 -- ie, the stuff that is stable. [07:51:54] right. I understand that. [07:52:17] Lots of the less stable stuff in 1.5 hides behind ifdefs at the moment. [07:54:44] I like Matt's idea of a regular 1.6 release discussion. it would be helpful to track how close we are to getting the release ready, because while I know of several DAFS issues, I have no idea at all which of them are considered in the critical path for 1.6. [07:55:09] 'DAFS stabilization' is too vague for me to wrap my brain around and try to break into small, solvable pieces. [07:56:12] at the moment there are changes from the DAFS code that broke 1.5 even when dafs is compiled out. those issues are clearly items that must be fixed. [07:56:17] I think the issue here is that most of the knowledge about DAFS issues exist in the bug tracker that some (most) of us can't see. [07:57:03] secureendpoints - could you point me to either an RT # or a delta (or set of deltas) -- I can take a look at that. [07:57:08] if dafs itself is not stable then either it gets compiled out or it must be pulled from the branch. the problem is that pulling it is a dangerous process itself [07:57:11] simon - very good point. [07:57:19] Ill see what can be done about that. [07:57:47] I can't point you are tickets in the RT I can't see. If I had a delta it would be a fix to the problem. [07:58:06] if you look in the openafs rt you will find several open tickets for volume creation problems with 1.5 [07:58:24] My gut feeling is that unless we have the stomach for some major culling (which seems, to me, like a huge waste of effort), the best answer to when 1.6.0 will be ready is "not yet" [07:58:41] you can also look at the openafs-info / openafs-devel list for e-mails from jason edgecombe and folks at mit that were trying to test the code [07:58:59] simon - I understand that, but it's not a -useful- answer. e.g., what is the -next step- towards 1.6? [07:59:08] ... and the best thing to get people who ask "When will 1.6.x be ready" to do is to test and file bugs. [07:59:40] the way we get to 1.6 is to first start with getting all of the issues that are known to be in 1.5 among ourselves addresssed [07:59:50] --- mcohan has left [07:59:54] that means that those who are developing must deploy it [07:59:59] And if they already know of bugs which aren't in _our_ RT, then put them there. Redact all the meaningful details if necessary, but at the moment, we're stumbling round a half lit room. [08:00:11] --- abo has left [08:00:21] --- abo has become available [08:00:31] --- mcohan has become available [08:00:51] I'll see about those bugs. [08:01:36] that seems at least to be a step in the right direction. [08:01:41] but seriously, it amazes me that none of the people that contributed the dafs code to 1.5 are actually running 1.5 deployments in their environment [08:02:27] I guess that doesn't amaze me at all: the word 'unstable' is rather off-putting for people. [08:02:55] once the known bugs are fixed and it becomes possible for "users" to deploy a new cell or upgrade their cell to 1.5.x and have a reasonable expectation that it should work, then we can create a new branch targeted at 1.6 and determine at that point what goes in and what must come out [08:03:52] more off-putting are the reports from people that have spent their time trying to help only finding that they can't even deploy a test cell because they can't create volumes or that volumes do not come online [08:04:35] secureendpoints - the problems the people testing have 1.5 have seen *are definitely* offputting. totally agree. [08:05:26] then you won't blame me if I do not encourage people to test something I know will leave a bad taste in their mouths [08:05:36] not at all. [08:12:33] * haba totally understandable [08:12:55] i'll just do a driveby and say imo dafs related issues are most of what's preventing 1.6 from happening, say, tomorrow. [08:14:26] dafs issues have been the blocking item on 1.6 for more than a year now [08:14:56] in some sense dafs is the equivalent of linux 2.6 from the 1.2 to 1.4 transistion [08:15:38] when trying to produce 1.4 stable series we had our backs up against a wall because we didn't have a good enough working solution for linux 2.6 [08:16:10] as a result more and more new features piled up on the 1.3 branch. things that people wanted but which they couldn't have. [08:17:21] the stable windows releases from 1.3.50 to 1.3.87 were on that branch for many of the same reasons that they are now on the 1.5 branch. [08:17:47] the changes necessary to support the new windows platforms were too significant to backport to *nix stable [08:19:40] of course now we have other features that people want. disconnected operations and the windows redirector that are not stable enough but people are expecting them in 1.6 because they have heard about them for too long [08:19:51] --- abo has left [08:20:46] --- abo has become available [08:31:33] --- Rrrrred has left [08:32:00] --- Rrrrred has become available [08:40:15] --- haba has left [08:47:44] Sorry I missed some of this discussion. I think there needs to be a stabilisation towards something called 1.6, one way or another. [08:49:49] Also, while I think every one of SecureEndpoints erm your points about DAFS implications are clearly valid, it's not the case that the contributors don't run DAFS. It's not a stabilised rw fileserver, clearly. [09:14:45] --- manfred furuholmen has left [09:14:59] --- manfred furuholmen has become available [09:23:32] The way we get to 1.6, given the current development model, is to stop committing new features to 1.5 long enough for it to stabilize. Otherwise it will never reach the point where the whole branch is something we can call stable. [09:25:15] freeping creaturism [09:45:52] One of the interesting things about disconnected operations is that intensively testing it is revealing races in the Unix CM which have been hidden for a long time due to either RX locks serialising things, or just from the difference in timing when you take the network away. [10:04:40] --- manfred furuholmen has left [10:09:46] --- Russ has become available [10:51:40] --- dev-zero@jabber.org has left [11:32:29] I suppose it's a good thing those bugs are being found finally [11:51:34] --- dev-zero@jabber.org has become available [13:07:36] I really should fix rxgen to emit a prototype for _ExecuteRequest when it builds its header files ... [13:45:39] --- manfred furuholmen has become available [13:55:33] Are we likely to be building on any platforms that don't have offsetof() in stddef.h ? [14:00:00] --- mcohan has left [14:00:19] --- mcohan has become available [14:08:21] --- mdionne has become available [14:11:53] --- manfred furuholmen has left [14:14:15] --- manfred furuholmen has become available [14:17:36] Thoughts on /afs/inf.ed.ac.uk/user/s/sxw/Public/openafs-better-queues.patch ? It tidies up the afs_q structure so that it's more usable in more places - disconnected is about to use it a lot more. [14:34:21] confirm just adds QEntry and uses it to implement QTO{V,C,VH}? [14:34:34] Yes. [14:34:43] Looks a lot less scary now. [14:34:50] I'm going to use QEntry a lot more in a forthcoming disconnected patch. [15:03:52] --- manfred furuholmen has left [15:05:51] --- manfred furuholmen has become available [15:14:35] --- manfred furuholmen has left [17:08:21] --- Dale Ghent has left [17:56:38] --- Russ has left: Disconnected [18:04:22] --- SecureEndpoints has left: Disconnected [18:16:09] --- SecureEndpoints has become available [18:40:54] --- mdionne has left [23:21:46] --- reuteras has become available [23:46:28] --- manfred furuholmen has become available