[00:06:23] --- dev-zero@jabber.org has left [00:21:36] I now use http://github.com/timcharper/git-helpers/blob/master/git-strip-new-whitespace to clean up my changes before I push them. But something that fails commits would be useful, too. [00:41:49] --- dev-zero@jabber.org has become available [01:29:52] --- Russ has left: Disconnected [01:41:53] --- Simon Wilkinson has left [01:59:16] --- haba has become available [02:37:56] --- stevenjenkins has left [02:37:56] --- stevenjenkins has become available [05:06:32] --- haba has left [05:10:26] --- haba has become available [05:51:57] --- matt has become available [05:52:04] I think I need that [06:00:59] i think we all need that [06:01:21] i'd also like the git commit hook that test-compiles-with-warnings-enabled. also, a pony [06:12:40] I sent you a pony last year...did you let it starve? [06:12:46] matt: can you please explain what you mean by testing with multiple virtual cpus? are you testing with more logical cpus then are in the system? or are you testing with two virtual cpus on an 8-way system? [06:13:09] just meant, I'm testing in vmware. [06:13:24] (On a machine which has real SMP) [06:13:30] perhaps you could just say that. [06:13:52] I thought I was. I'll use the other phrasing in future. [06:16:09] I would suggest "tested on Centos x86_64 in vmware configured with 2-cpus on a physical 8-way system running xyz OS." [06:16:21] Noted. [06:16:36] --- abo has left [06:17:26] --- abo has become available [06:17:49] I have access to simulators that claim 1024 CPUs that run on systems with fewer physical cpus. Those simulators would not provide any significant testing of thread safety issues. [06:20:13] I believe that I've effectively tested the 2 changes on 2-way SMP (2 logical, 2 physical). It is Centos 5.3 x86_64. [06:29:03] steven: why do you believe that permitting gnu-style long options requires a documentation change? the change is meant to prevent typos from becoming an error. I do not believe we should be encouraging users to use gnu-style with OpenAFS since it is likely to result in unhappiness when those users find it doesn't work everywhere. [06:29:38] documentation should reflect reality. [06:30:15] ie, undocumented items over the long haul tend to cause more problems. [06:31:36] not all documentation is created equal. [06:32:01] --- haba has left [06:32:02] end user documentation should reduce complexity and instruct users on how to best use the tools. [06:33:23] (jaltman: description fixed) [06:34:48] I think you're overgeneralizing there. Yes, I agree with both of those statements; however, the purpose of man pages (and other -reference- documentation) is to be complete and correct. [06:35:44] user guides, admin guides, etc, point out 'how to best use the tools'. and it makes sense to me to *not* mention the gnu-style in the user and admin guides (hence the specific note I made in gerrit that updating the one afs.pod doc would be sufficient, IMO). [06:40:57] --- matt has left [06:47:41] we will see what others have to say. I do not believe it is required. [06:47:59] as for the docs for "fs listacl". be patient [06:56:29] is the afslore wiki down? [06:56:36] (ie, it's not responding to me) [06:57:06] www.dementia.org keeps running out of memory. [06:58:53] > the purpose of man pages (and other -reference- documentation) is to be > complete and correct. No. The purpose of man pages is to document the advertised behavior of software. If you document it in a man page, it becomes an interface we have to support. [07:00:18] --- matt has become available [07:01:06] --- deason has become available [07:02:56] are you suggesting that gnu-style options might thus be removed someday, so we shouldn't mention support for them anywhere? [07:03:51] that was my point. its not part of the command interface. the change is being made as a convenience. that's all. [07:08:16] I guess I don't see the point of adding support for something but not documenting it. In my experience, undocumented options end up in lots of local documents mentioning the undocumented features, and various processes relying on the undocumented features, all causing more work in the long run for both the software maintainers, and the local admins/users. [07:09:08] I'm asserting that making them work is a smaller change than making them work and documenting them as working, and that the latter is something we need to decide to do explicitly. [07:10:40] on --enable-checking not building, I have some patches in the works to fix some of them [07:11:12] Note that the documentation appears online, and people include excerpts from it or things derived from it in presentations, etc. If I tell a room full of people to run "rxdebug --nodally" and they go home and it doesn't work because their AFS wasn't released yesterday... [07:11:34] off the top of my head, there's several places we need afs_mumble_printable_lu, there's some signedness issues in rxkad, and some type-punning related warnings in some places I don't remember [07:12:08] if you give me a day or two I can get them in; I wanted to wait until I believed I got everything at least for one platform, so I am more sure I got all of one class of warnings [07:14:23] andrew: I'm sure the warnings aren't going away by themselves :) [07:16:42] --- haba has become available [07:17:48] --- Russ has become available [07:26:34] --- Russ has left: Replaced by new connection [07:26:34] --- Russ has become available [08:04:04] simple gerrit question: how do I pull down a commit that's not yet in git? (apologies for the FAQ, but as dementia isn't responding, I can't get to Simon's docs that probably already have this documented) [08:04:23] there's an instruction in every gerrit "incident" [08:04:27] e.g, how do I pull 586 [08:04:53] "do what 586 says" [08:05:28] oh. it doesn't tell you until you log in [08:05:39] I can open it up in a web browser, but I'd like to cherry-pick it. [08:05:45] (I'm logged in, btw) [08:06:10] there should be a line that it gives you a 'copy' button to copy in to the paste buffer [08:06:18] and you don't get "download" below "author" and "committer"? [08:06:21] and you can 'git clone' that or something to get it [08:06:30] in the "patch set 1" section? [08:06:52] I see a 'download' field, but it's not a button. [08:07:34] it looks like a link, but nothing happens when I click on it (yes, User Problem). [08:08:27] what's in the download field? i have a "git pull" command in it, and a button to the right of it which uses javascript to copy into your paste buffer [08:08:59] the download field is empty [08:09:39] then the wiki is unlikely to help you [08:09:42] the 'copy' button on the right is flash, actually, iirc [08:10:16] flash. oh. [08:10:34] hm, in fact it is [08:10:49] that's fairly problematic for my desktop. [08:11:00] stby [08:11:01] but the key word there is 'my'. [08:11:02] well, it should just be the button, you should be able to see the link without flash [08:11:19] the 'link' being the text, not an actual clickable link [08:11:44] well, i wonder if he never loaded an ssh key and so it's not giving him a git url [08:12:54] i get a download url from my necessarily-non-flash-supprting cellphone [08:13:07] so the issue is something else [08:13:37] shadow - no key showing; will pursue that a bit. [08:14:14] --- haba has left [08:15:19] --- abo has left [08:16:16] --- abo has become available [08:16:22] now, what in the world is VIOC_FS_CMD supposed to do since Hartmut didn't bother to provide an implementation for the Windows cache manager. [08:16:30] --- haba has become available [08:17:55] guess what other platform he didn't include one for [08:19:59] looks like Unix :) [08:44:59] > but the key word there is 'my'. No, it's not. This interface should not require flash. [08:48:37] It doesn't. [08:48:40] I turn off Flash. [08:49:00] The only thing that uses flash is a little button to copy the git line into your paste buffer if you're too lazy to select it with the mouse. [08:49:05] You can disable it in your preferences. [08:51:25] > No, it's not. This interface should not require flash. [08:51:37] jeff should catch up before ranting about something which is factually incorrect. [08:52:08] and if he missed it, i'll remind him: works from my necessarily-not-flash-having cellphone. [09:32:57] --- haba has left [11:04:54] --- jaltman has left: Replaced by new connection [11:04:55] --- jaltman has become available [11:13:35] --- dev-zero@jabber.org has left [11:58:24] --- Russ has left: Replaced by new connection [11:58:24] --- Russ has become available [12:27:24] --- dev-zero@jabber.org has become available [12:44:31] --- matt has left [12:56:39] --- matt has become available [12:58:30] I think I recall from the hackathon that branching a 1.6 is something that's going to happen fairly soon--am I recalling that aright? [13:01:41] after the rpc changes [13:02:05] ah [13:40:24] --- mdionne has become available [13:43:10] > e.g, how do I pull 586 [13:43:39] "gerrit-cherry-pick 586" ? [13:44:15] or gerrit-cherry-pick 586/n , where n is the patch set number [14:02:53] --- tkeiser has become available [14:22:13] --- matt has left [14:34:21] --- tkeiser has left [14:36:42] --- kula has left [14:55:53] --- kula has become available [15:04:10] --- kula has left [15:05:11] --- mdionne has left [15:34:17] --- kula has become available [15:43:35] --- deason has left [16:35:30] --- deason has become available [17:13:44] --- jaltman has left: Replaced by new connection [17:13:45] --- jaltman has become available [17:36:49] --- jaltman has left: Disconnected [18:43:11] --- deason has left [18:44:06] --- deason has become available [19:43:45] --- Jeffrey Altman has become available [20:22:34] --- dev-zero@jabber.org has left [21:49:27] --- deason has left [22:03:47] --- dev-zero@jabber.org has become available [22:20:51] --- Claudio Bisegni has become available [22:47:41] --- dev-zero@jabber.org has left [22:48:08] --- dev-zero@jabber.org has become available [23:03:38] --- Jeffrey Altman has left: Replaced by new connection