[00:05:43] --- dev-zero@jabber.org has left [00:38:28] --- brantgurga has left [00:41:47] --- dev-zero@jabber.org has become available [01:17:30] --- pod has become available [01:21:41] --- haba has become available [01:24:59] nio out-of-office-meddelanden [01:25:20] rong room [02:20:58] --- RedFyre has left [02:21:04] --- dwbotsch has become available [04:16:43] --- brantgurga has become available [05:07:23] It looks like commit messages to openafs-cvs are still getting stuck somewhere. Could somebody deal? [05:21:06] --- Claudio Bisegni has become available [05:24:22] --- Claudio Bisegni has left [05:32:14] --- Jeffrey Altman has left: Replaced by new connection [05:57:18] --- Jeffrey Altman has become available [06:16:02] --- Claudio Bisegni has become available [06:24:57] the issue was actually "too big" not "approved sender" [06:25:51] Ah, too many changes in the RCSID patch? [06:27:00] BTW: Sorry about the current blizzard of changes. I'm trying to clear out my old git and quilt patch stacks. [06:38:44] no appologies required. please send more. [06:49:15] --- reuteras has left [06:53:51] --- Russ has become available [06:54:43] Indeed. This is a problem that we love having. [06:55:29] speak for yourself. it is a problem i am not averse to having. problems i like having are "where did this money come from" and "what am i going to do with all this beer" [06:55:55] I wouldn't have thought you'd ever find the latter to be a real problem ... [06:56:19] I suspect with sufficient increase in the beer, it could become one. :) [06:56:35] "5 liters is one too many"? [06:56:43] At some level of beer quantity the laptop starts shorting out. [07:00:34] That's just really a problem of pacing, though. [07:05:27] --- deason has become available [07:44:35] Derrick: Shall I go ahead and push the parallel make change? It looks good to me. [07:44:45] i want to try it on irix [07:44:52] Oh, okay. [07:45:06] actually, i know what i want to do [07:45:10] i will try it shortly [07:45:12] Russ: In response to you "how did this ever work" question, jhutz explained this to me at the workshop. [07:45:22] I want to hear this one. [07:45:27] 'cause that code is AWESOME. [07:45:41] You have char a[256]; Then &a == a; [07:45:55] ...oh, yeah, that's right. [07:46:07] Man, C should not be surprising me with odd corners after this long. [07:46:09] The things you learn with decades old code. [07:46:42] that this has worked for decades. [07:47:15] We also have places where we have function arguments that are arrays. That gets even more exciting. [07:47:30] Yeah, that I'm more familiar with. [07:47:49] can i get gerrit to give me a patch? [07:48:07] Hmmm. But gitweb will. [07:48:18] yeah, i don't see that either [07:48:19] Click on the 'gitweb' link beside the patchset SHA1 in gerrit. [07:48:21] unless it's "raw" [07:48:25] i'm already there [07:48:41] i guess in fact "raw" would be it [07:49:08] Yeh. raw does it for me. [07:49:09] --- deason has left [07:49:37] --- abo has left [07:49:48] BTW: I'm _really_ enjoying the new toolset. I don't know how others are finding it ... [07:49:51] --- abo has become available [07:50:02] I haven't swtiched over yet [07:50:05] I'll do that this weekend [07:50:23] gerrit is nice. i'd like a way of forcing the pull/test compile to happen automatically. that will come with time, i am sure [07:50:31] --- stevenjenkins has left [07:51:07] Yes. We've adopted gerrit at work too, for a project that has continuous integration as one of its requirements. I'm hoping a colleague will do the necessary work. [07:51:23] what continuous integration software would they likely pick? [07:51:36] You can tell from how much code review that I'm doing when I never did that before how much I'm loving it. :) [07:52:21] --- deason has become available [07:52:27] You don't really need software with gerrit. [07:52:46] i need an sshd and keys known to it? [07:53:36] You need a ssh client with a known key. Then you watch gerrit. When a change appears, you fetch it (over anonymous git). You build it, you report back (using the ssh interface). [07:53:57] You only need software if you have a pool of multiple machines, and you want to manage the load sensibly between them all. [07:56:00] --- Claudio Bisegni has left [07:56:14] --- stevenjenkins has become available [07:57:28] * Russ thinks we need an afs_strlcpy. [07:57:41] Looking at src/vol/namei_ops.c, it's just riddled with strcpy and strcat. [07:58:03] src/util/strlcpy [07:58:03] snprintf gets awkward. strlcpy and strlcat are nice to replace a bunch of that. [07:58:10] Oh, we have it already? Cool. [07:58:31] but in the case I commented on where we are combining two strings afs_snprintf() is a better choice [07:58:40] Yeah, agreed. [07:58:43] GitDeveloper says [07:58:44] git log -p origin/..HEAD [07:58:49] which appears to not be right [07:59:06] In what way? [07:59:10] It works for me, although is not your working branch here -- it's master. [07:59:15] in the "gives me an" [07:59:17] ah [07:59:24] Yeah, that confused me too the first time I read it. [07:59:28] the reason that snprintf() is renamed to afs_snprintf() is because there are so many broken snprintf() implementations out there. [07:59:38] it does say upstream branch. i am just stupid [07:59:54] for strlcpy/strlcat you can just use strlcpy/strlcat. we build only if the platform does not support it [08:00:48] we also now have afs_asprintf() [08:00:52] AC_REPLACE_FUNCS them into libafsutil [08:01:07] --- haba has left [08:01:32] which should make it much easier to dynamically allocate strings and avoid using stack variables [08:01:36] --- haba has become available [08:02:10] I'd argue that that patch isn't the right place to make that change. [08:02:21] * Russ is working on a cleanup of that file right now. [08:02:34] probably not. [08:02:52] --- deason has left [08:03:15] --- stevenjenkins has left [08:03:18] I still plan to implement the Microsoft Safe String Library for OpenAFS [08:03:23] --- abo has left [08:04:03] after that someone can go module by module and update all of the string processing [08:04:04] --- abo has become available [08:05:15] apparently i did something wrong, and pushed change 25. sorry [08:06:10] --- deason has become available [08:07:55] Just abandon it, and all should be well again. [08:08:28] Ah, and rebase 26 to origin/master [08:08:55] Oh, and reset whatever you're working from to origin/master to - you seem to have dependencies on a couple of pushed changes there. [08:09:48] --- stevenjenkins has become available [08:22:00] --- Derrick Brashear has left [08:24:24] Jeff: http://gerrit.openafs.org/29 includes that afs_snprintf change if you want to review. [08:47:10] * Russ is really tempted to do a global s/register // [08:47:25] Go for it. [08:47:55] Once the rest of my prototype changes have landed, we should be safe from 'register var;' nonsense too. [08:49:42] Ah, #define private static [08:49:43] Lovely. [08:49:45] That's what private is. [08:50:02] Mutter. What possesses people to do that sort of thing? [08:50:21] The language has enough perfectly good keywords without making up new ones. [08:54:31] Wow, big fan of the place where we allocate 2KB of memory and then just forget about the pointer. *heh* [08:58:10] Is our coding style to explicitly cast void pointers when assigning them? [08:58:29] I personally prefer not to add the cast in that case since I think it's visual noise, but I know other people disagree. [09:04:26] I think it depends. [09:04:47] My style has been that where the pointer has been passed in as a rock, I cast it to make clear what's happening. [09:08:50] We should stop using _DIR_FILE_H defines for header guards. _[A-Z] is reserved by the C standard. [09:10:21] C99 7.1.3.1: "All identifiers that begin with an underscore and either an uppercase letter or another underscore are always reserved for any use." [09:11:19] Have I done that, or is that in existing code? [09:11:38] You added a new header in the ptserver cleanup but you're just following existing coding style. [09:11:50] I think your change is fine and we should do a global cleanup. [09:20:44] * Russ finishes reviewing all patches in Gerrit. Which rocks. [09:21:04] I should probably pull some of these and verify them and push them. [09:22:06] I'm verifying everything I submit before pushing it. I guess we need to agree on what 'Verified' means, and whether the submitter can set it themselves if they've tested their code. [09:22:45] And what the definition of verify is for what we're talking about. Does it just mean it compiles for things like the warning cleanups? [09:23:08] Indeed. [09:23:22] BTW: "stdarg.h" is because this is kernel, not userspace, code. [09:23:49] Are we providing our own stdarg.h somewhere? [09:23:59] Nope. That comes from the kernel headers. [09:24:10] Then why would we use "" instead of <>? [09:24:20] Because some platforms make use. [09:24:22] what "verified" means to me is that at a minimum the code was compiled. I think it needs to be compiled by someone other than the committer [09:24:26] s/use/us/ [09:24:42] But not for netinet/in.h, which is right below it and uses <>? [09:24:59] and for things that look dangerous I would like to see it compiled on multiple platforms as part of verification [09:25:21] at a minimum one *nix and one Windows [09:25:29] Yeh, we're not consistent :) [09:25:59] If I build Simon's warning patches, should I go ahead and submit them, or do you want to test those on Windows as well? (In other words, what sort of dangerous metric are you thinking of?) [09:26:10] Basically, with this patch, Derrick and I went round and round with osi_Panic finding something that worked everywhere. I've just taken the osi_Panic stuff and transplanted it to afs_warn(). [09:26:11] --- deason has left [09:26:19] --- stevenjenkins has left [09:26:22] Anything that adds a new header file should get built on Windows, I think. [09:26:36] Stuff that doesn't add new headers, should be fine. [09:29:30] --- deason has become available [09:31:22] if you are adding a new header, be sure to add it to the Windows NTMakefile [09:31:37] Yeh. Sorry. [09:32:57] --- stevenjenkins has become available [09:45:58] So does anything that adds a new header need NTMakefile changes? [09:46:19] I think anything that adds a new, exported, header definitely needs changes to NTMakefile. [09:46:35] I was wondering about the addition of src/ptserver/display.h in 22. [09:46:45] It's an internal header. [09:46:48] Well, it won't break the build. [09:47:29] But it will break the dependency checks. Judging from the diifferences between the NTMakefiles and the normal Makefiles, dependencies are pretty broken already. [09:48:49] dependencies are very broken [09:49:22] lots of changes to the Unix makefiles that were never made to the Windows NTMakefile. I just would rather it not get worse. [09:49:46] Okay, I should respin change 22 then. [09:52:46] Actually, ptserver has no internal header dependencies on Windows at all. So, change 22 is good to go. [09:54:25] thanks for checking [10:07:36] --- Derrick Brashear has become available [10:08:03] > the issue was actually "too big" not "approved sender" OK, so should I raise the limit a bunch/ [10:08:15] anything which is not immediately obvious to me as "will work" i hacve reverified [10:09:33] jhutz: What's the limit at the moment? [10:09:42] > function arguments that are arrays. In other words, abominatons. [10:10:41] > I'm _really_ enjoying the new toolset. I think I will be, too. I'm just afraid to clone the repository on anything less than CMU wired network. [10:10:52] i've cloned on a tethered iphone [10:10:57] repeatedly [10:14:19] > The language has enough perfectly good keywords s/enough/too many/, if you ask me. [10:15:07] The repository clone really isn't that bad. [10:15:58] the afslore GitDevelopers page mentions it's a 150M-ish download... is that really the case? [10:16:05] I believe so, yes. [10:16:07] du -sh .git tells me only around 60ish [10:16:18] I would have thought a clone wouldn't pull down much more than that [10:16:38] Although git also compresses the download. 150M is the figure Jeff gave me. I haven't actually metered it. [10:16:40] i get 67mb [10:16:42] --- Jeffrey Altman has left [10:16:44] Same here. [10:16:50] --- Jeffrey Altman has become available [10:17:23] Has anyone done a git clone recently enough to remember what it reports? [10:18:07] --- shadow@gmail.com/owl1A15EC91 has become available [10:18:11] the file size is abuot 67MB but the actual disk allocation with 4K blocks is 150MB [10:20:41] Receiving objects: 100% (109618/109618), 57.59 MiB | 1050 KiB/s, done. [10:20:59] The current limit is 40k [10:21:17] We're only sending diffstat output, so the worst we'll get is a long list of filenames. [10:21:24] I suspect that 128k would be more than sufficient. [10:22:12] In practice, it's very unlikely that we'll have many changes the size of the RCSID removal, which touched a rather large percentage of the files in the tree. [10:22:26] Although if I do a global s/register //, that will be similar. [10:24:30] Oh, well, if that's all, perhaps I'll just do it from here. The network here isn't all that bad, as long as you're not too close to the front of the restaurant. [10:26:02] I can set it to anything we want, including "unlimited". [10:40:21] should we have a jabber chat room which can only receive git commit messages? [10:41:25] instead of the e-mail notifications? [10:41:29] no [10:41:39] in addition [10:41:46] I doubt I would use it [10:41:57] I don't think I would use it. Too noisy. [10:42:38] would it be too noisy for this room? [10:42:44] Definitely. [10:43:16] oh yes [10:45:11] conceivably someone could write something to batch them so you only get, say, 1/hour at most, but.... eh [10:45:28] meh [10:48:14] Russ: Sorry about 27. It would appear that I am a muppet. [10:48:19] No problem. :) [10:48:39] I apparently am blind, too, since visual inspection didn't turn up any of that. [10:49:03] The thing is, if I hadn't got AFS_LINUX_26_ENV instead of AFS_LINUX26_ENV you wouldn't have noticed it :) [10:50:57] * Russ laughs. [10:51:12] That one is going to need to be built on AIX before submitting too, I think, to test the other branch of the code. [10:51:21] Indeed. [10:51:38] And Tiger, if anyone still has it sitting around. [10:51:55] i do [10:52:16] Cool. I'll push a new change shortly, just as soon as the one I'm currently testing is done. [10:52:23] aix 5 and 6 will be the real issues [10:52:45] It's a carbon copy of the osi_Panic() code, so providing I haven't made any more typos, we should be good. [11:20:08] simon: you broke the windows build by including rx.h in src/utils/netutils.c [11:20:46] Sorry. [11:20:52] Ack, sorry, I didn't realize that was something that would be fragile. [11:20:56] I have a dependency loop between rx and utils [11:21:02] Tell me what to do to fix it, so I know what to do in future. [11:21:11] Ah - your rx depends on utils? [11:21:15] yes [11:21:48] oh. we discovered this once before. [11:21:54] yes we did [11:22:02] How did that ever work? util calls into rx [11:22:04] ifndef AFS_NT40_ENV it [11:22:22] it worked very fragilely [11:22:40] Jeffrey: Do you want me to submit that change? [11:22:43] rx is linked to the static library created by utils to get functions that are not present on Windows [11:23:12] But don't you have linker problems - rx requires objects provided by utils, but utils requires objects provided by rx ... [11:23:22] what is the warning that you are removing by include rx.h? [11:23:42] Well, search for rx in netutils.c. [11:23:52] Basically, all of those functions aren't prototyped without that header. [11:24:34] (well, just rx_getAllAddrMaskMtu() ), but it does need to be there. [11:24:58] --- stevenjenkins has left [11:25:36] --- haba has left [11:26:27] --- haba has become available [11:27:13] (warnings from rx_getAllAddrMaskMtu caller) [11:28:08] what I need to do is add a new rx_headers build stage [11:28:18] Unix has rx_depinstall [11:28:20] --- Jeffrey Altman has left [11:28:28] --- Jeffrey Altman has become available [11:30:49] --- stevenjenkins has become available [11:36:35] Jeff: You want to git rebase origin/master before submitting or you end up submitting merge commits. [11:36:46] which i did yesterday. it sucks. [11:36:48] yep. [11:36:54] Ah, you got it already. [11:37:04] you can use e.g. git log -p origin/master..HEAD [11:37:08] to see what you'll push [11:37:21] BTW, for verifying, the procedure I use is: [11:38:13] git checkout master git pull --rebase git checkout -b tmp-verify copy/paste git line from Gerrit build and test as necessary and then add comments, review to Gerrit git checkout master git branch -D tmp-verify [11:39:15] If I need to change things on the tmp-verify branch, I commit the change, run git rebase --interactive origin/head, squash as needed, and then git push to the update URL. [11:39:43] You can just git commit -a --amend, if you want to omit that rebase. [11:40:03] The git command from Gerrit creates a merge. [11:40:09] You need the rebase to get rid of it. [11:40:23] The pull does? Ah, Ok. [11:40:30] But yeah, you can simplify the rebase to not need squash with git --amend, good point. [11:41:00] git commit --amend being equivalent to a git commit followed by a git rebase --squash in an already rebased branch. [11:41:35] Well, git rebase doesn't have a --squash flag. But you know what I mean. [11:41:41] how do I reverse a pull? [11:42:16] Not easily. [11:42:25] Have you pulled into a topic branch? [11:43:13] reverse a pull? push! but that's not what you mean [11:44:06] If you've pulled a load of changes you don't want to be there into a topic branch, they way I've always gone about fixing it is just starting again. [11:44:20] just starting again seems to be the easiest way [11:44:24] yeah [11:44:30] Make a new topic branch, and cherry-pick the changes that you _want_ to be there into that branch. [11:45:30] i need to go to git bootcamp [11:45:38] me too [11:45:58] the kauth prototypes work on Windows [11:49:04] --- abo has left [11:49:41] --- abo has become available [11:50:01] --- deason has left [12:11:56] --- dev-zero@jabber.org has left [12:18:56] afs/vol_prototypes.h had to be added to the vol/NTMakefile [12:19:05] Gah. Sorry. [12:19:23] I knew there was something that had a Windows impact, but I guess it went through before we started checking. [12:19:55] In the long term, is there any way both sets of build files could come from the same source/ [12:20:20] we could play the MIT game but I actually find that to be worse [12:20:34] Okay. You're the one who sees the pain, I guess. [12:20:55] Although if we could hook a Windows machine up to gerrit and get it to auto-verify, that would catch a lot of this. [12:21:48] vos.c 4594 ccode undeclared identifier [12:22:04] Hmmm. Not seeing that on Unix. Let me look. [12:22:20] The vos changes require re-running configure or you get weird errors. [12:22:25] Dunno if that's what you're seeing. [12:22:32] Windows is not HAVE_POSIX_REGEX [12:22:42] and there is no configure on widnows [12:22:51] Ah, then no, not what you're seeing. [12:23:05] Simon, did you rename ccode to code ? [12:23:28] I don't think I would have. Hang on, need to clear what I'm working on out of my tree, and then I'll take a look. [12:23:42] --- abo has left [12:24:01] --- abo has become available [12:24:11] --- haba has left [12:24:20] --- stevenjenkins has left [12:24:41] --- haba has become available [12:25:52] I assume size_t is safe to use in shared code, right? [12:25:55] Bah. My bad, sorry. [12:27:05] you removed the variable instead of conditionalizing it [12:27:10] Yup. [12:27:21] Patch to fix, on its way. [12:28:10] Russ. on Windows size_t can be used. The thing to know is that size_t is 32-bit on 32-bit Windows and 64-bit on 64-bit Windows. It does not have to be the same size as time_t. and it does not have to be the same size as a pointer. [12:28:24] yeah, that's okay. [12:28:27] I just hate using int for offsets. [12:28:40] size_t feels like the right data type, even if it's never going to be bigger than 10 or 15. [12:29:43] http://gerrit.openafs.org/40 [12:30:02] --- abo has left [12:30:18] --- abo has become available [12:31:00] --- stevenjenkins has become available [12:36:07] hm. fc_test can't be built on irix. [12:36:47] also, i'm not sure why it should be built for "all" and not a test target anyway [12:37:31] Is that as a result of my changes? [12:37:57] afs/bucoord_prototypes.h needs to be published as well [12:38:17] well, the issue is fc_test needs libsys on iric [12:38:20] and not elsewhere [12:38:23] for rxi_syscall [12:38:42] Ah. [12:39:22] Jeffrey: What's the right way of doing that/ [12:39:49] --- abo has left [12:40:48] --- abo has become available [12:41:06] anything that is going to be referenced as "afs/xxxx" must be installed into $(DESTDIR)\include\afs [12:41:49] Adding $(DESTDIR)\include\afs\bucoord_prototypes.h to the INCFILES list in the NTMakefile will perform the install [12:42:26] Okay. I'll knock up a patch to do that. Sorry about this! [12:42:33] I'm taking care of it [12:46:53] --- dev-zero@jabber.org has become available [13:02:45] --- Derrick Brashear has left [13:08:13] --- brantgurga has left [13:15:49] Other massive search and replaces that I'm not doing but that I find horribly tempting: s/(\s*)$void$/$1/ [13:16:45] Er, anchored at the beginning of a line, sorry. [13:16:52] Basically, all the casts to void of function calls. [13:17:22] --- dev-zero@jabber.org has left [13:19:03] Yeh. That would be good, too. [13:19:47] --- Derrick Brashear has become available [13:23:13] Are you sure you want to do that? Aren't there compilers that complain when you call functions in void context that return non-void, or at least that return pointers? [13:24:26] I doubt it a lot. [13:24:35] Given how many people call strcpy without a void cast in all sorts of code. [13:25:20] I've never used that cast to void style in any of my code and I stripped it out of INN and never got a complaint. [13:26:20] 1980s-vintage lint will complain, but at this point gcc with a bunch of -W options is a way better lint than lint. [13:30:42] --- mdionne has become available [14:30:27] --- dev-zero@jabber.org has become available [14:35:13] --- brantgurga has become available [14:56:39] How many people will I mess up if I rename all the manuals to have better file names, rename the directories to not use StudlyCaps, and rename the xml directory to manual so that we're not naming directories after their file format? [14:56:57] Now is probably a good time to do it. [14:57:02] Will I break the documentation stuff on the web site? [14:57:05] I would imagine you'd mess up yourself and Jason. [14:57:20] I think Jeffrey is the only one who knows how docs.openafs.org is built. [14:57:31] There's one pending patch which would require rebasing, but I can do that. [14:57:38] Or Jason can. [14:58:24] I want to stop shipping files named auagd000.pdf in the openafs-doc Debian package, and the best way to do that is to change the names of the source files to be a bit less strange. [14:58:33] That seems fair. [14:58:42] And if I'm going to rename things, I may as well get all the renaming over with at once. [14:58:46] Yeh. [15:07:17] --- brantgurga has left [15:08:51] docs.openafs.org is /afs/grand.central.org/www/docs.openafs.org I don't know how it's generated, but http://www.openafs.org/doc/ is no longer just an export of files in the repository. [15:09:11] (presumably you mean jaltman knows how it's generated, which may be true) [15:09:43] Yes - he set it up. [15:09:51] --- Jeffrey Altman has left: Disconnected [15:10:25] --- Jeffrey Altman has become available [15:11:08] judging from what I keep building and then having a compile break afterwards, it may be docbook [15:11:46] Yes - it's definitely docbook. We just don't know where the script is that builds it. [15:12:42] the script? its the build system for openafs [15:12:55] Do you do it manually? [15:12:57] the contents of docs.openafs.org is just a copy from the build tree [15:13:11] Oh, okay. So if I move things around, that doesn't break anything automated. [15:13:18] I just need to keep the top-level index.html working. [15:13:52] I suppose it might be useful to have an .htaccess that redirects the old pages... do we care? [15:13:54] yes [15:13:59] And the new tree is new enough that if you're going to break existing URL's, now is the time to do it. [15:14:16] what are you thinking of moving around? [15:14:40] Note that the new tree is different enough from what was in openafs.org/docs that I didn't try to be specific about redirection; instead the whole thing is just redirected to the top level of the new site. [15:14:48] --- haba has left [15:15:27] Renaming the files so that they're not cryptic strings like auagd000.xml and instead are admin-guide.xml and then chapter1.xml, chapter2.xml, etc. Renaming the directories so that they're admin-guide, quick-start-unix, etc. instead of AdminGuide to follow our directory naming elsewhere and what's more normal for UNIX. And while I'm moving things anyway, moving xml to manual so that it's not named for the document format. [15:15:38] --- haba has become available [15:16:11] I can either leave ReleaseNotesWindows alone or rename it as well as you prefer. [15:16:12] If we do this on HEAD, we probably want to do it for 1.4, too. [15:17:00] --- stevenjenkins has left [15:17:17] Actually, probably unix-quickstart and, if you want the renaming, windows-relnotes, to put the OS first for directory grouping in case we have more stuff later. [15:18:13] And yeah, we should pull it up since otherwise we won't be able to pull up later manual patches. [15:18:25] Although I really hope 1.4 isn't that long for this world. [15:18:28] feel free to rename but just make sure that you open a ticket for what needs to be done to fixup the windows build system and installers after the fact. I didn't like the names that were there when I started working on them. But they had already been committed and were in use. [15:18:53] Okay. [15:18:59] Hopefully we should be able to open the git tree for 1.4 commits after this weekend. [15:19:08] I should write a script to make pullups easier, too. [15:19:34] I would suggest holding off on the renaming until after 1.4.11 [15:19:38] Even better than that script, since cherry-pick -x is fairly easy, would be a script to show which commits aren't pulled up. [15:19:45] git cherry [15:19:45] but make sure it happens before 1.5.61 [15:19:56] Ah, nice. [15:20:05] I think 1.4.11 is pretty much done. [15:20:10] I need to write some tools before we can do 1.5.61, anyway. [15:20:16] At least, I don't think anything I do in Git is going to change 1.4.11 at this point. [15:20:19] Tarballs for 1.4.11 went to release builders tonight. [15:20:35] Don't make any changes on the 1.4 branch in git. [15:20:36] but is it tagged in git? [15:20:41] No, that's true. [15:20:53] If 1.4.11 respins, then there will be changes in CVS for that, which we'll have to pull over manually to git. [15:20:55] Although that's a nice thing about Git: retroactive tags are about as easy as regular tags. [15:21:09] But yeah, we don't want to pull anything up until we're sure 1.4.11 is done. [15:21:13] We don't want git to be ahead of CVS. [15:21:42] just be patient [15:23:06] --- stevenjenkins has become available [15:50:30] I think we've increased our patch application velocity considerably, although it does help that Simon's warning cleanups are fairly easy. :) [15:50:48] Yeh. [15:51:12] And I'm not actually writing these as I go. I'm taking old patches, updating them to the current tree, checking they still build, and submitting. [15:51:29] I also suspect that over half the review comments made are things we wouldn't have fixed previously. [15:51:42] True. But when fixing them is so easy ... [15:51:49] Yeah, it's lovely. [15:52:31] Although I seem to have lost the change for 46 in my local tree. Its not where I thought I left it. [16:00:01] * Russ heads home. [16:00:03] --- Russ has left: Disconnected [16:18:19] --- kula has left [16:19:57] --- rra has become available [16:32:28] so things we've submitted that are in RT, should we resubmit via gerrit? [16:33:07] --- kula has become available [16:33:12] If you want to, then yes. [16:33:37] My plan was to take a pass through RT at some point, and pull patches out of there into gerrit. But if someone else gets there first, then so much the better. [16:34:19] ok; I may do that t his weekend if you don't beat me to it. [16:34:44] I doubt I will beat you to it. Hazel's home this weekend... [16:36:31] mdionne: Does you review of change 49 mean that it added warnings? [16:36:49] No, it removed 32 warnings [16:36:57] Ah. Phew. [16:37:13] BTW, overall I have more warnings now than before the last few days commits... [16:37:22] Yes. I suspect you will. [16:37:44] probably related to the prototyping I assume [16:37:55] Instead of a single warning (or none at all if you weren't building -Wall) about having a missing prototype, you'll now get lots of type warnings. [16:38:00] Yes. [16:38:24] The warnings go down dramatically if you have --enable-warnings on. I can see why they would go up if you're building without that. [16:38:32] Do you test on 64-bit? I see many warnings related to integer vs pointer size on 64-bit [16:38:58] not new ones btw [16:38:59] I'm not currently testing the warnings patches on 64 bit. [16:39:27] for instance VNLog takes 32-bit arguments, but we pass it 64-bit pointers in some places [16:39:37] Basically, warnings reduction is what I do on my laptop on the train when I want something mindless to do. 32bit laptop, so no 64bit testing :) [16:40:17] VNLog's one of things that ought to be replaced by va_args, IIRC. [16:41:37] --- stevenjenkins has left [16:41:49] --- abo has left [16:42:07] --- abo has become available [16:42:54] gerrit-cherry-pick is nice for pulling changes for testing [16:43:01] Indeed. [16:43:35] It means you don't end up with the merge commits that git pull can give you. [16:45:02] so anytime you push and your parent is not the current head on the server, you'll get one of those merge commits? [16:45:58] You're okay if the parent is an older commit on HEAD. [16:46:07] I'm thinking I'll do a little script to automate creating a test branch, pulling a change and compiling it. should be all of 2-3 lines [16:46:14] You shouldn't get a merge commit from a push. [16:46:35] rra: ok, then that's fine. I was worrying that you always have to be up to date to push [16:46:48] I think the merge commits we were seeing was because people had a merge commit in their local branch, and then pushed a change. [16:48:16] When you do a push, gerrit basically finds all of the objects that are reachable from the point you are pushing, that aren't reachable from its tree, and creates changes for them. So, you get the merge commits pulled in too. [16:48:24] --- stevenjenkins has become available [16:56:41] so if you have a clean tree (if not up to date) with only your changes, you should be OK. [16:56:53] Yes. [16:57:03] The way to check is with the .. operator [16:57:29] if you have multiple commits, do those show up as a single change? [16:57:45] No. [16:57:58] Each commit will be its own change. The changes will be marked as dependencies. [16:58:06] So, if you have A--B--C--D in git [16:58:15] You'll have change 1, 2, 3, 4 in gerrit. [16:58:28] Change 2 won't get submitted until change 1 has been, and so on. [16:58:31] Should that generally be avoided, because of the dependence? [16:58:57] It can make sense to use it, if you have things that are truly dependent, and that you want upstream to see as different commits. [16:59:13] Where it becomes tricky is if you are asked to make changes to a change in the middle (say B) [16:59:31] Ok, so it would be the way to do "patch sets" [16:59:47] If that happens, you need to rebase the change into B, and then reupload it. But you also need to reupload C and D, too, as they have changed in gits eyes. [17:00:17] (because a commit is both what that commit contains, and the hash of the object before that commit) [17:01:37] --- abo has left [17:01:52] So you would have to resubmit the whole thing. I saw that the idea of a group of related patches is on the gerrit wishlist [17:02:06] --- abo has become available [17:02:19] Yes. It's not there yet. [17:02:52] Basically, as far as I can tell, Gerrit is Shawn Pearce coding as fast as he can, whilst also putting out all of the Android build fires that flare up around him. [17:03:00] That would be useful for submitting large features that you want to cut up in nice sized patches [17:03:13] --- dev-zero@jabber.org has left [17:03:55] I think for really big things, the best way to handle them is to build them in your own cloned tree, and ask people to do an initial review in that tree. Then push them into gerrit when there is consensus about the right size of each patch set. [17:04:37] --- haba has left [17:05:21] --- haba has become available [17:05:22] could we eventually host developer trees on git.openafs.org - like they do on git.kernel.org. would be useful for those types of reviews [17:05:39] I can't see why we couldn't. [17:05:55] Yup. [17:06:04] You can also use gerrit in a gitosis kind of a way, to simply provide an authenticated way of pushing into trees [17:06:54] Which makes it easier to handle permissions. [17:07:29] so use gerrit to manage those other trees as well? [17:07:48] Well, not to enforce code review, but to authorize access. [17:08:08] --- abo has left [17:08:13] (Basically, you can configure access in gerrit so people get to push to the 'real' branch, and not to the code review one) [17:09:06] --- abo has become available [17:09:12] Ok, and I assume gerrit can handle multiple trees at its end [17:09:17] Yes. [17:09:31] It's used for android. And they have lots, and lots, and lots, and lots of trees. [17:13:10] would you be able to manipulate such trees remotely - creating/deleting branches, rebasing, etc.. [17:13:34] You would only be able to push to them, and manage branches. [17:16:13] still useful as a way to publish early work without affecting the main repository [17:16:23] Indeed. [17:17:17] I definitely don't want the gerrit system for openafs.git to end up being used for a way of displaying proof of concept patches. If something ends up there, its because the author believes its ready to ship. [17:17:25] Simon: There are various other warning cleanups mixed into 50. It all looks good to me, though, so I don't know how anal to be, but it's not mentioned in the commit message. (There's a typo in the commit message too.) [17:17:35]