[00:09:09] --- Russ has left: Disconnected [06:36:00] jblaine: Feel free to holler if you are having git woe... [10:02:14] --- asedeno has become available [10:07:15] --- jaltman/FrogsLeap has left: Replaced by new connection [10:08:10] --- jaltman/FrogsLeap has become available [10:08:54] --- jaltman/FrogsLeap has left: Disconnected [10:14:36] --- jaltman/FrogsLeap has become available [10:36:12] --- Russ has become available [14:24:19] --- jaltman/FrogsLeap has left: Disconnected [14:26:57] --- jaltman/FrogsLeap has become available [15:41:31] Regarding *_linux3 sysnames (http://gerrit.openafs.org/4843): I still think adding *_linux3 sysnames is a bad idea for the reasons I gave in my comments there, but in the interest of trying to get this resolved one way or the other before 1.6.0, I wrote this patch series that copies the _*linux26 sysnames to *_linux3. /afs/athena.mit.edu/user/a/n/andersk/Public/openafs/openafs-linux3-sysname.patch Which way do we want to handle this? [15:42:54] submit to gerrit and after posting it there, comment in each gerrit patchset that the alternate version exists. request feedback there [15:43:19] Give the main use of sysnames is in the @sys link, and Linux 3 doesn't change userspace, I'm not sure we should bump the sysname. [15:45:44] That’s my argument as well. (It also doesn’t particularly change kernelspace either; I didn’t have to make any changes other than detecting the version number correctly.) [15:46:19] Yeah, essentially Linus just got bored with 2.6 [15:46:54] I suspect, actually, that we should never have had linux22, linux24 and linux26. [15:54:28] Want to comment on #4843, so you and Marc can come to an agreement? [15:55:23] Yeah, I'll do that [16:07:24] Commented. [16:28:42] does anyone happen to have some vlserver stats lying around I could look at? (or be willing to do a quick vlclient and send me the output) [16:30:10] vlclient? [16:30:19] yes. [16:30:41] vlclient $server -getstats [16:31:04] what is this vlclient and where can I get it :P [16:31:31] better yet, can you run that on your own if I give you some hostnames? [16:31:42] um. src/vlserver/vlclient [16:31:46] yes, that will work. [16:31:59] afs-db{1,2,3}.bx.psu.edu [16:32:04] tx. [17:17:28] --- deason/gmail has become available [17:23:15] --- jblaine has become available [17:23:40] does it bother anyone else that we have 'cdb', something-debug, and somethingdebug ? [17:24:08] for example, cdb, fssync-debug, rxdebug [17:25:20] pardon, cbd, not cdb [17:25:39] sure. tools were developed at different times by different developers. they are all things that openafs inherited [17:26:12] people know and rely upon the names that exist. there is no pressing need to change them. [17:27:26] Sure, I agree. It's a nitpick definitely. Just one of those things to me... I would have changed them at a major release. [17:27:37] with the old versions reporting EOL [17:27:38] I wouldn't. [17:27:45] Obviously :) [17:27:52] that would break scripts that rely upon them and cause users pain [17:28:34] Instead, we punish those who expect a consistent user experience. [17:28:49] It's a mental break. [17:29:00] If you were really bothered, we could install hard links from one to the other. [17:29:08] But, to date, other things have bothered people more. [17:29:53] I'm just saying it's selective reasoning, IMO. [17:30:34] If we were writing it from scratch, we'd try to be consistent. But we're not, and we can't break deployed code. [17:30:55] So, the only options are a) the status quo, or b) shipping the same binary with multiple names [17:30:56] How long is that stay of execution? [17:31:22] In terms of not breaking people's scripts? I think it depends on the reason behind the change [17:31:25] What came first, rxdebug or fssync-debug? [17:31:58] If it's - "there's this really serious problem, which we can't fix without changing the script", then that's one thing. If its "things would look much nicer if we did X", then that's another. [17:32:27] Okay, so different deprecation periods. One shorter, the other longer. [17:33:12] I think the second one is pretty much indefinite, sadly. I don't believe that "things would look nicer" is a good enough excuse for breaking running code. [17:33:20] That's pretty much why transarc paths still exist. [17:33:30] Like I said, it's selective reasoning. By doing X, you hurt group A. By leaving things as-is, it's not without its downside. [17:33:35] (jaltman+simon) +1 [17:33:41] Not "look nicer" [17:33:50] It's a user-interface experience issue. [17:33:56] agreed. [17:34:11] but the 'break stuff' is a serious issue as well [17:34:21] Of course it is. [17:34:31] Nobody suggested enable it for 1.6... [17:34:35] your time window will be at least ten years [17:34:49] That's sad. [17:35:35] our code is deployed in organizations that literally cannot upgrade deployed machines (NASA) and must be able to support a broad range of versions across a long time window. [17:36:29] other organizations do upgrade (every three to five years) but the upgrades are global and no one can tell you what scripts rely on what tools. If we break them, we will cause a serious financial impact and what little funding openafs receives will go away fast. [17:36:39] backward compatibility matter. [17:37:56] the entire perl interface to afs relies on particular formatting of the fs, vos, pts, etc. commands which is why we are so loath to make changes there. Those commands are a much bigger user experience issue than some debugging commands which are only to be used by "experts" [17:38:43] steven.jenkins: do you want any stats for a longer period of time? bx seems to just be from the past few hours [17:39:20] one snapshot is fine [17:39:35] (I'm having to build a VM and build openafs in order to pull down psu's..) [17:39:54] I mean, from a dbserver that's been on for longer than that [17:39:55] Every day the deprecation statements aren't in place is another day 10 years from now that these things will have to be supported. [17:40:15] as long as it has had at least one client hit it for something, that's all I need. [17:40:17] In ten years it won't be any safer [17:40:33] deprecation doesn't mean it is safe to remove. [17:40:59] Deprecation with notice every time the command is run doesn't? [17:41:02] for 10 years? [17:41:10] a deprecation notice will break scripts [17:41:16] all of the 'debug' commands are debugging tools that you shouldn't be touching unless you know what you're doing anyway.... or they're running from a script [17:41:24] deason: You're missing the point. [17:41:35] forest/trees issue [17:41:37] I don't think so [17:41:46] if there are similar issues in "fs" or whatever, then sure, we'd be more receptive [17:41:48] you are simply looking at the wrong forest [17:42:01] You're right. [17:42:17] but if you're talking about the end-user experience with fssync-debug... man, someone that has to guess at the name really shouldn't be running fssync-debug [17:42:24] We're quite happy to consider making changes where the risk/reward balance is weighted the right way. [17:43:15] So, don't fix things that are named wrong. [17:43:21] Like cvs.html --> source-repo.html [17:43:46] that isn't code [17:43:48] don't just assume everything agrees with what I say [17:43:55] err, everyone [17:44:07] and I wouldn't mind that move if some kind of redirect was in play; I even suggested how to do the redirect [17:44:44] I don't think anyone is saying that, I think what people are saying is "there are a variety of definitions of 'wrong', and there are a lot of reasons some of those 'wrong's are actually closer to 'right'" [17:44:51] that was an incredibly abstract sentence [17:45:00] I'm just clarifying (for myself) the environment I'm trying to take part in better. [17:45:43] And clarify the "Open" in OpenAFS more accurately in my head. [17:46:10] the problems for consistent names and such should be fixed more "urgently" the more they're run by newbies or run by people in everyday scenarios [17:46:11] there's a lot of history with AFS, and some of that history forces staying power on things that ideally might be different [17:47:03] Open means that you are free to take the code and make local changes to it to your heart's content. You are free to use it for free. You are free to read the source code and documentation. You are free to submit patches. You are not free to break other user's deployments and that is what the gatekeepers are charged with preventing. [17:47:12] Yes, Andrew, and I'm saying that without a start somewhere, the rare commands will never be "fixed" [17:47:24] yes, and I'm saying it's fine that the internal commands are never fixed [17:47:32] You are also free to take the code and call it something without AFS or OpenAFS in the name and do what you want with it. [17:47:46] it's really hard for me to see anyone getting turned away from the project or fed up with all of this stuff because the debugging commands are inconsistent [17:47:51] And ultimately, someone will say, "gee, you know, if we had started something around that in 2000, we could change this in 2 releases from now" [17:48:14] However, if you call it something with AFS or OpenAFS in the name, you will be sued for trademark violation by IBM. [17:48:20] It depends on what level of detail you are interested in, Andrew [17:48:21] if you're using those commands, you're experienced enough.... [17:48:35] It's not a matter of being experienced enough. [17:49:14] I enjoy polishing. [17:49:17] if you are capable of understanding the output of those commands you either are experienced or have read plenty of documentation or more than likely source code [17:49:30] That's, again, not the point. [17:50:04] I just don't understand whose experience you're trying to make better [17:50:09] command names are public interfaces which third party code rely upon. We don't break public interfaces unless there is an extremely important reason to do so. [17:50:16] It's 1 example, deason [17:50:37] How about: The next guy. [17:50:40] then give different examples; you can change the others with backwards-compatible dealies in place [17:51:07] the "command names are public interfaces" probably wouldn't be so rigid if we had other non-suck machine-usable interfaces, but we don't [17:51:11] Just because you guys have been up to your eyeballs in this stuff for 10-20 years... for that reason alone, makes you incapable of seeing my point perhaps [17:51:27] Jeffrey: I understand what you're saying. Thank you. [17:51:41] It's devolved into a much more big picture thing now. [17:52:00] jblaine: I don't think anyone is missing your point, just disagreeing with your reasons [17:52:16] Okay, let me rephrase it. [17:52:51] dude, it's like you're asking to change the ordering of struct members in a library interface; it will and does break things [17:53:01] I understand exactly what you are saying. You want to be able to ship a polished self consistent product in two years time in order to make things easier for new users to adopt and understand. [17:53:16] Thank you. [17:53:55] That's exactly my point, but 2... 10... 15 years doesn't matter. [17:54:03] the point is that our existing 20 years of deployed clients, servers and system administration code is much more important to us since we are dependent upon them for our future. [17:54:48] Yes, I get that now after this discussion. That's news to me (the funding ball and chain). [17:54:52] and AFS already has a long history of being fragile and too dangerous to run. We are not going to make the impressions of OpenAFS by managements around the world worse. [17:55:17] Its not even the funding. OpenAFS gets nearly zero funding. [17:55:40] I was not aware that those funding us (or whatever you want to call it) we're that unreasonable. [17:55:42] Its the not having AFS ripped out of organizations that we rely upon for non-monetary support [17:56:21] They are very reasonable until you start breaking their infrastructure. [17:56:22] I figured at worst, 1.2 might be service at some places. [17:56:39] um, AFS 3.6 is still in service [17:56:52] in fact I know of at least one production system with AFS 3.5 clients [17:57:22] Okay, so I understand the dependency relationship now. Good to know. [17:57:48] Doesn't change my original point, though clearly negates the command-name change idea, even over 10 years. [17:58:06] I'm glad someone at least gets what I am getting at. [17:58:26] History matters. [17:58:39] Here [17:59:21] It doesn't matter in Linux and that is why it is so painful keeping OpenAFS working on the Linux kernel [17:59:24] I still see issue reports involving machines from pre-openafs, too [17:59:41] there's a balance that can be found, Jeff [17:59:52] I agree re: Linux * [18:00:24] If I can sneak in with a different topic, I was reviewing the diff of afs_pioctl.c between 1.4 and 1.6 (for auditing the scripts.mit.edu patch), and noticed that the (doxygen?) comments for PSetAcl and PGetAcl have VIOCSETAL and VIOCGETAL, respectively. Those are typos that should be fixed, right? [18:01:30] not typos [18:01:53] those are the names of the pioctl command values [18:02:07] Ah. [18:03:25] BTW, I found that the AFS_SUN5_ENV block re: Solaris 10 deadlock dates back to the 2000 (or obviously earlier) IBM release [18:12:22] jaltman: to me, it becomes a matter of who is responsible for an infrastructure that breaks from a change after N years of notice. I hear you saying, "OpenAFS is responsible for it, no matter what." [18:14:10] and I just don't buy that (and it doesn't matter even minutely what I "buy", I get that) [18:14:29] Oh well. [18:15:36] well, so, intellectually, it may be that at some level, keeping up with an API is on the people using it. That said, when there are big things that can't keep up with an API dependent on an old on, the responsibility arguably falls to those providing the API [18:15:46] (API here being a loose term) [19:38:09] VIOCSETAL? "set access list". not a typo. [19:40:51] Hmm, who do I need to buy beer to get a 1.6.0pre6 SRPM available on the website? [19:41:55] i think simon may have one but sadly i don't have it. lemme see if it's in the afsbuild dropoff [19:42:13] it is. hang on [19:44:56] I also have freebsd binary builds that don't panic on unmount, if you feel like pulling those in, too. [19:46:04] are all the patches in gerrit at least? [19:46:28] Yeah. Though a couple are for master only, at the moment. [19:50:07] there. issue a pullup and then give me a path to the binaries and i will do it [20:08:12] Pullups in gerrit (looks like we missed the 'make dest' fixes from a while ago, too). Binaries in /afs/sipb.mit.edu/project/freebsd/openafs/{amd64_fbsd{81,82,90},i386_fbsd_90}/openafs-1.6.0.p6.tbz [20:15:36] copying those. srpm is there. need to regen web page [20:45:42] theoretically the web page is updated [22:35:10] --- deason/gmail has left [23:44:29] Russ: I’m guessing that e0a94ba (Remove and symlink the Doxygen-generated jquery copies) is unnecessary now that http://bugs.debian.org/622147 is closed, and will in fact fail on the rm line? That’s what happens on older Ubuntu releases, at least.