[01:04:28] --- dev-zero@jabber.org has become available [01:17:10] --- dev-zero@jabber.org has left: offline [05:05:47] --- cclausen has left [05:30:19] --- Jeffrey Altman has left: Replaced by new connection [06:08:01] --- Jeffrey Altman has become available [06:53:25] --- Derrick Brashear has left [06:54:31] --- deason has become available [07:21:55] --- Derrick Brashear has become available [07:45:25] --- haba has left [07:48:40] Simon, your grand account was set up right away; it should work fine. The CVSROOT is in /afs/.grand.cental.org/project/gco/cvs But the stuff in /afs/.gco is probably not up to date at the moment, since it appears the last few days' worth of autosync jobs seem to be stuck in disk wait in the rsync on the openafs/cvs tree. [07:49:31] i bet his ssh keys aren't right [07:51:07] istr jason had this problem, and the answer is that file should be authorized_keys2, which i just created [07:51:22] also, i gave him a copy of cvs anyway [07:52:52] It's maintained by the same set of individuals that maintain the openafs.org infrastructure. [07:53:17] The data in the numbers tree is old; the registrars are working on that. [07:54:22] re: info-afs yeah, it's dead. we nominally took it over, but IBM wouldn't share the list membership data, and really, there's no point any more. [08:39:32] dafs-fsa.dot is missing where things start, though at least the disposition ("freed") is shown. [08:48:48] --- dev-zero@jabber.org has become available [08:48:52] --- dev-zero@jabber.org has left: offline [08:51:07] --- reuteras has left [08:56:39] I think we should create a new RT queue somewhere that can be used for afs3-standardization issue tracking. [08:57:00] which we [08:57:18] the registrars most likely [08:57:28] so we not being we [08:57:51] although we as in openafs having appointed a registrar are clearly involved [08:57:57] What sort of issue tracking. and why the registrars? we have a queue for registrar stuff. Maybe this is an issue for the standardization group chairs? [08:57:57] sure [08:57:59] or could be [08:58:25] submitting requests to the mailing list is fine but they are just going to end up getting lost [09:14:24] --- sxw has become available [09:15:49] I think there is a distinction between the standardisation group chairs, and the registrars. [09:16:21] How the registrars organise themselves is really a matter for them - I seem to recall people arguing that point strongly when my document was being discussed. [09:17:08] someone should construct that RT queue and since we do not have chairs at the moment .... [09:18:05] But I don't think the chairs are involved at all. [09:19:05] The registrars are a separate body. Our only real ability to influence them is to depose them if they aren't serving the communities interests ... [09:19:42] do you have an opinion on who should create this RT queue? [09:20:49] If the registrars want to have an RT queue to handle incoming assignment requests, then they should make one. But I'd really like the registration process to be a black box - requests go in, assignments come out. I don't really care how the internals of that box function, providing the process happens in a timely fashion. [09:22:32] Ah, but we're talking at cross purposes. [09:22:48] for those who have not read the most recent afs3-stds e-mails, there is a proposal on the table that individuals that would like to see RPC changes occur file a submission of their protocol requirements within 30 days. The requirements will then be compiled into a table for discussion by the community to determine what should or should not go into a major overhaul of the AFS3 protocol RPC set. [09:22:54] With regards to AFS standardisation, my intention was that all of this stuff should get sent to the list. [09:23:07] And I'll then collate them into a final document. [09:23:16] Personally, I'd rather not have any more RT queues in my life. [09:23:51] (sorry - I hadn't caught up on afs3-stds ) [09:25:14] my concern with sending to the list is that I fear things will get lost [09:25:46] I don't believe they will, and I think there's sufficient time within the process for anything that does get dropped to be picked up again. [09:25:56] --- abo has left [09:25:58] afs3-stds is archived, after all. [09:26:19] --- abo has become available [09:26:42] feel free to respond as such to the e-mail sitting in the afs3-stds list [09:31:47] the registrars _have_ an RT queue to handle assignment requests. [09:32:09] Yeh. Confused. Meh. [09:33:55] I think the 30 days/1 year thing is a bit harsh. [09:36:38] Exceptional circumstances can over-rule. But there was a stated desire from implementors not to have to handle a rash of RPC revisions. [09:36:54] And we need to accomplish this process in a timely fashion - there are effort issues. [09:40:07] Yeah, I know. What I'd like to see is some sort of extensibility model that will make it relatively easy to add new features without the overhead of new RPC's and without negatively impacting performance. But that'll take time to design and get consensus on, so it'll have to be next cycle. [09:40:54] Yes. I think an extension mechanism would be wonderful. And I think work on designing that counts as 'exceptional' so wouldn't be constrained by an restrictions from this process. [09:41:27] It will be interesting to see how many submissions we get ... Hartmut seems very keen to find fields in existing structures, rather than defining new ones! [09:41:40] 30 days might be too short for me given that as part of the process of reviewing all of the RPCs for 32-bit to 64-bit conversions for time values (among other things) I want to finish updating the protocol specification docs to match what we currently are using. [09:42:06] shy of introducing tagged and/or counted fields in payload, which has its own issues, i suspect doing anything extremely flexible is hard; and those would include their own unpleasant issues [09:42:24] unless we are willing to restrict the moratorium to specific packages such as RXAFS [09:42:58] I think the moratorium is just for RPCs we've just changed. [09:43:12] So, if we revise FetchStatus, we're committing not to revise it again for a bit. [09:43:30] changing the status structure is going to affect just about the entire package [09:43:40] Yeh. There will be knock ons. [09:43:53] and if we are going to change time representation that is going to affect just about every package [09:44:04] But do you have to do it all at once? [09:44:25] we do not have to update every package at once [09:44:25] Or can you just change the time type in one package (or a subset of one package), and not in others. [09:44:38] that may cause collateral damage [09:44:53] It may, but how many 64bit times are we seeing at the moment? [09:44:56] e.g. correctly represented time "inadvertantly" getting damaged by another package [09:45:08] but I suspect we are not going to want to update the implementation to use 64-bit time values until all of the associated packages are updated [09:45:32] One of the things I'd like to be able to do is decouple things as much as we can. [09:45:47] So we can roll these changes out in a gradual way, without having to have big bang code changes. [09:45:50] --- stevenjenkins has left [09:45:50] --- deason has left [09:45:54] its not that we are seeing 64-bit time at the moment but that we need to write code to manage the 64-bit to 32-bit overflow cases [09:46:02] So, we could have 64bit values in the RPCs, but only use the bottom 32 bits for a while. [09:46:04] --- abo has left [09:46:04] --- deason has become available [09:46:15] --- abo has become available [09:46:33] --- dev-zero@jabber.org has become available [09:46:57] I don't think we're going to be able to use the presence of the new RPCs to determine the capabilities of the client or the server. [09:47:27] that is what capability bits are for [09:47:42] Inded. [09:47:43] for a flags field in the structure itself that indicates what fields are valid [09:47:55] s/for/or [09:48:05] Yes. [09:48:30] So, bubbling up a little. Do you think that 'by the end of July' for initial proposals is too aggressive? [09:48:54] And if it is, what timescale would be more convenient? [09:49:07] --- stevenjenkins has become available [09:50:08] given that we're spinning up this process, it might be. in general that sort of timeframe probably isn't. would august 15 be more convenient or does it skew too late to the academic year? [09:50:59] Anything over the summer is going to hit problems, I guess. [09:51:28] well, i was thinking more in terms of "once academic time starts, which people we need time from will be busy, suddenly" [09:51:31] My major concerns were getting something done quickly enough that it doesn't unduly delay rxosd, and taking enough time that we don't have to do it all again. [09:51:46] a delicate balancing act, yes [09:52:59] --- dev-zero@jabber.org has left: offline [09:54:26] > we do not have to update every package at once But if we're considering sweeping changes like changing the time format, we should at least consider updating everything at once, or at least thinking very carefully about what we're going to update when, what the interactions are when only some interfaces have been updated, and what the implications are for signalling which interfaces are updated. [09:55:56] I don't think doing a wholesale revision of every single RPC in a single pass is going to happen with the effort available to us. [09:56:55] Well, the first question is, do we want to try to _finish_ this "soon", or make adopting it one of the first things the standardation does under the new process? If the latter, there won't be a chair seated until October, and we should plan the timeline for submissions and discussion such that we are likely to reach consensus shortly after that. "ha ha" [09:57:08] I think we want to do this soon. [09:57:25] Or at least, we want to do some of this soon. [09:57:45] No, me either. But if we're going to do something with sweeping effects, but not all at once, we need to group the changes reasonably. It would suck to define a hundred capability bits because we update fields one at a time. [09:57:56] Indeed. [09:58:37] There's a possibility that Edinburgh may host a hackathon in late September (the week before Rome). If that happens, it would seem like the perfect place to discuss all of this face to face. [09:59:51] I don't see the point in doing nothing now, and twiddling our thumbs until a process appears. [09:59:55] So, one thing we could do is roll together a bunch of "easy" low-effort, non-controversial things into an as-soon-as-possible update, and defer harder things for the standardization group, which then might re-rev some RPC's sooner than a year from now (and maybe a third time in less than a year for extensibility, if that doesn't make it into the second pass). But after that, the rate of change would be expected to slow considerably. [10:01:48] I think that would be fine. [10:02:46] > I don't see the point in doing nothing now, and twiddling our thumbs > until a process appears. Oh, of course not. But we could collected proposed changes now, with a slightly less agressive deadline than 30 days, and then discuss them without having to have a process in place. My presumption is that the process allows anyone to talk about anything any place/time, and also that if the mailing list is the process's official forum, then anything that happened on that list before the process is fully spun up still counts as having taken place in that forum. [10:03:06] Yes. [10:03:31] But I'd like to hear suggestions on what an appropriate, yet less aggressive, deadline might be. [10:03:40] (I know Derrick has said mid-August) [10:03:51] --- Derrick Brashear has left: Lost connection [10:03:51] --- summatusmentis has left: Lost connection [10:03:51] --- dwbotsch has left: Lost connection [10:03:51] --- shadow@gmail.com/owl912329A2 has left: Lost connection [10:03:51] --- kula has left: Lost connection [10:03:51] --- RedBear has left: Lost connection [10:04:16] --- Russ has become available [10:04:35] So, do we take the path that gets most things done in 2009Q4 and maybe adds extensiblity later, or the one that gets some things done in 2009Q3, the rest in 2010Q1 or Q2, and maybe adds extensibility later? [10:05:01] --- summatusmentis has become available [10:05:12] My preference would be for the latter. [10:05:21] Call those A and B [10:05:27] --- dwbotsch has become available [10:05:28] For B, then. [10:05:29] --- RedBear has become available [10:06:07] Changing location ... back in 10 minutes or so ... [10:06:09] --- Derrick Brashear has become available [10:06:18] --- sxw has left [10:06:21] --- kula has become available [10:06:51] The B path more or less requires proposals submitted no sooner than end-of-July, and even that may be pushing it. I think proposals like "I want to change all of the times to 64 bits, at least in any RPC that we're modifying anyway; I'll provide a list of them later" are fine, as long as "later" means by end-of-August or so. [10:08:15] --- shadow@gmail.com/owl912329A2 has become available [10:08:25] The A path would allow proposals as late as the end of September, with discussion running concurrently and the understanding that the more controversial your proposal is, the sooner you're going to have to bring it up in order to convince people to take it in this pass. [10:08:41] (actually that understanding applies to both paths) [10:15:27] --- Derrick Brashear has left [10:21:44] --- Derrick Brashear has become available [10:30:42] jhutz: Do you want to summarise your arguments for the standardisation list? [11:02:42] --- dev-zero@jabber.org has become available [11:13:59] --- Derrick Brashear has left [11:17:25] --- Derrick Brashear has become available [11:26:09] --- dev-zero@jabber.org has left: offline [11:47:38] Um. Not really. I mean, yes, I want them to appear there, but no, I don't really want to spend the time to do it. :-) I suppose I will do so anyway. [11:48:07] IIRC you were going to go back and look at some pending issue wrt the afs3-stds charter [11:53:46] Oh, here it is: From Derrick, on 22-Sep-2008: > Make vote-takers check that nominees consent to being nominated before > adding them to the list of candidates. [11:55:55] --- Derrick Brashear has left [11:56:02] --- Derrick Brashear has become available [12:00:15] well, yes [12:02:02] Not controversial; just the only known comment since draft-3 [12:02:26] Though I think we might find it easier to elect chairs without that provision [12:03:00] electing chairs versus nomination to be included at all is different [12:06:41] No, I mean it will be easier to elect chairs if we allow people to be nominated without their consent. :-) [12:07:01] stby. this isn't my problem :) [12:12:26] --- Derrick Brashear has left [12:21:58] --- sxw has become available [12:25:48] --- Derrick Brashear has become available [14:07:08] --- Jeffrey Altman has left [14:17:35] --- Jeffrey Altman has become available [14:19:05] --- Jeffrey Altman has left [14:46:33] --- Jeffrey Altman has become available [15:55:25] --- Derrick Brashear has left [16:01:07] --- Derrick Brashear has become available [17:36:12] --- edgester has become available [17:52:36] --- cclausen has become available [17:53:45] --- summatusmentis has left [17:54:12] --- summatusmentis has become available [18:04:42] --- cclausen has left [18:04:45] --- deason has left [18:05:47] --- deason has become available [18:18:17] --- cclausen has become available [18:43:24] --- edgester has left [22:40:20] --- deason has left [23:00:15] --- reuteras has become available [23:10:58] --- dev-zero@jabber.org has become available [23:34:25] --- dev-zero@jabber.org has left: offline