[00:12:09] --- cclausen has left [01:04:34] --- Russ has left: Disconnected [01:20:51] --- haba has become available [01:36:52] --- dev-zero@jabber.org has left [01:53:03] --- haba has left [02:03:21] --- dev-zero@jabber.org has become available [03:29:33] --- RedBear has left [03:36:38] --- sxw has become available [03:37:35] I don't think putting the newsletter on its own list is a good idea - we want it to be as available as possible. In fact, I'm wondering why it wasn't sent to openafs-info and openafs-devel this time round. [03:43:10] See, I would expect the opinion of subscribers to openafs-announce to be that your desire for the newsletter to be "as available as possible" does not trump their desire to not get extra stuff. [03:44:36] I don't think it counts as 'extra stuff'. [03:45:12] It doesn't change the volume on that mailing list particular, and it provides useful information to the community. [04:04:25] We'll see. [04:28:50] --- stevenjenkins has left [04:34:13] --- stevenjenkins has become available [04:40:26] --- stevenjenkins has left [04:44:56] --- stevenjenkins has become available [04:54:02] --- stevenjenkins has left [04:58:18] --- stevenjenkins has become available [05:13:49] --- stevenjenkins has left [05:18:42] --- stevenjenkins has become available [05:28:52] --- mmeffie has become available [05:29:34] --- Jeffrey Altman has left: Replaced by new connection [06:33:28] We've got a Linux server where user tokens seem to be getting thown away at random intervals. Anyone got any ideas of what to look for? [06:33:49] (1.4.10, RHEL5 2.6.18-92.1.13) [06:40:31] --- deason has become available [06:48:53] --- matt has become available [06:50:07] (feels to me like announce is where I expect to find the newletter) [06:53:19] nothing logged, i assume [06:53:35] and what's the GCPAGs value? [07:32:30] Nothing at all logged. [07:39:09] --- Derrick Brashear has left [07:40:40] --- Jeffrey Altman has become available [07:40:58] GCPAGs is 8. [07:45:15] ? [07:45:36] nevermind. [07:52:59] --- Derrick Brashear has become available [07:57:23] so if GCPAGs is 8, GCPAGs should not be eating tokens now. which implies if the problem is ongoing, one of 1) PAG tracking issues 2) silent discard [08:05:19] --- cg2v has become available [08:28:25] The process are all still in PAGs, and the group numbers remain constant across PAG discard. [08:28:34] Sorry, across token discard. [08:30:13] --- stevenjenkins has left [08:33:48] --- stevenjenkins has become available [08:38:15] --- cg2v has left [08:38:58] --- cg2v has become available [08:43:19] --- stevenjenkins has left [08:47:04] --- stevenjenkins has become available [08:49:11] --- sxw has left [09:54:28] --- Russ has become available [09:56:11] --- dev-zero@jabber.org has left [10:08:46] --- reuteras has left [10:27:19] --- Russ has left: Disconnected [10:57:26] --- cg2v has left [11:01:34] --- dev-zero@jabber.org has become available [11:05:25] --- Derrick Brashear has left [11:20:43] --- Derrick Brashear has become available [12:36:03] --- sxw has become available [12:47:59] Did we not fix RT #124923 once already? [12:49:19] looking [12:49:50] conn->afs_conn? did it even get onto 1.4? [12:50:08] no [12:50:28] --- sxw has left [12:53:56] --- sxw has become available [12:54:38] Git tells me that it's DEVEL15-rename-conn-to-afs-conn-20090121 [12:54:45] it is [12:54:59] didn't i say that? i have it up in front of me. [12:55:02] oh. i did to RT [12:55:17] I take it that never got pulled up? [12:55:19] oops, sorry, didn't check if it was elsewhere [12:55:27] no, not in 1.4.11rc1 anyway [12:55:36] 1.4.x is boring. if you gie me a patch for 1.4.x you've done *nothing* [12:55:38] Ah, Derrick said already. [12:57:59] this is the problem with balancing the conservative and liberal people [12:58:03] so, with the move to git, we'll have one code base, and pull release branches from that codebase? [12:58:08] i want a steel cage match [12:58:18] "works" versus "i hate myself" [12:58:26] You've said that before. I think it could be fun. [12:58:32] jake, you're an optimist [12:59:01] meaning that's the theory, but we'll see how it works? :-P [12:59:15] yup [12:59:23] i say many thing [12:59:27] most are serios [12:59:33] "serious" [12:59:37] stupid latency [12:59:54] you don't expect it to work that way? [13:00:00] summatusmentis: The way that git works best is if you push from a branch back into the head, for all changes that belong on the branch. [13:00:08] i expect nothing [13:00:08] That's really hard to do with our current development model. [13:00:11] i will wait and see [13:00:16] anyway, back shortly [13:00:32] --- Derrick Brashear has left [13:01:09] simon, that sounds like we'd have to plan features for release, and only accept those features into a branch [13:01:13] (It's also pretty hard to do if you have a branch that's diverged massively from your head) [13:01:46] Yeh. I don't think it works for our kind of project. It works for the Linux folks because they don't have the concept of 'stable' and 'development'. [13:02:25] there've gotta be people who do, and are using git though [13:03:00] --- deason has left [13:03:04] Yeh. They use the cherrypick model, generally. Which I think is probably the way we'll end up working. [13:03:39] so only pulling certain features from branches back into head [13:03:51] --- deason has become available [13:04:33] I should go back at look at your slides at some point [13:08:06] --- sxw has left [13:20:48] --- Derrick Brashear has become available [13:36:59] > simon, that sounds like we'd have to plan features for release in theory we already do that [13:37:03] it's a nice theory [13:37:22] well, like, long-term planning, timeframes, etc. etc. :) [13:38:48] you haven't looked at many of my past slide shows [13:38:52] that or you are rich [13:39:32] when i had employers who nominally cared, i had very little resources. now i have me. what exactly can i promise to deliver out of my spare time? [13:39:52] I'm not rich [13:42:23] I'm not saying "come up with a timeframe" just that if we were going to be having "release branches" to pull back into head, we'd need a plan [13:43:48] jake: having a plan and being able to execute on that plan are two very different things [13:44:45] it is extremely hard to plan any result that is dependent upon many resources that you do not have any control over doing the thing you require in the time frame you require it. [13:45:01] oh, absolutely, things happen. I was thinking conceptually. [13:45:16] coming up with a timeframe would be tremendously valuable. [13:45:20] I don't think you necessarily do need a plan. For example, I don't think that the Linux kernel has a plan, for example. [13:45:33] i have many plans. some of them date back to 2004 or earlier. [13:45:44] its not that things happen to slow you down. its that nobody tells you when they might get something done or even that they are doing it [13:45:48] What you do need is a clear determination of where each submission should sit before you land it. [13:46:18] determining where somethibg should lanbd and then having the thing it depends on be 4 years late won't make people happy [13:46:51] Yeh. I don't think merge from branch is an desirable model for us. It just doesn't fit the way we work. [13:47:05] which is reasonable [13:47:07] we can adapt how we work [13:47:17] how we work has adapted from the tools we had [13:47:21] I don't think we should. [13:47:30] i.... disagree somewhat [13:47:37] I don't think merge from branch fits the way our contributors work. [13:47:51] well, we already do worse than that [13:47:56] I think if we're adapting how we work to fit something more structured would require either more people, or more time [13:47:59] or both [13:48:10] I think bake on head, pull up when ready works relatively well. [13:48:28] not enough people use head, alas. [13:48:30] The other option is bake out of tree, merge when done. [13:48:39] that also has issues [13:48:49] i don't know what "happy medium" is [13:48:59] --- abo has left [13:49:13] I think having a single development branch, and cherry picking from that is a pretty good model. [13:49:22] --- abo has become available [13:49:30] the problem is head hasn't functioned as that branch in a while [13:49:32] that assumes it tracks stable pretty well [13:49:51] Not really, not nearly as much as commiting on stable then merging to head does. [13:50:09] commit on stable merge to head is destabiliszing [13:50:14] without the extra s [13:50:34] or z, if you are british [13:50:36] By head I'm meaning our new fangled head/1.5 branch, not the graveyard-for-broken-code-formerly-known-as-HEAD [13:50:45] well, that's the issue [13:51:05] without graveyard for broken code, things weren't getting somewhere people would see. with it, they weren't tested [13:51:14] I think we just don't merge code that isn't ready for develop. It lives on a branch, either in our tree or the contributors clone. [13:51:26] And we publicise branches more. [13:51:39] publicity will work if people promise to try it [13:51:48] and that works better for clients than servers [13:51:56] --- stevenjenkins has left [13:51:59] that is, imo, the crux of our problem [13:52:09] I think we've proved that people don't try 1.5, let alone anything more adventurous. [13:52:24] for clients that's less true [13:52:35] Fileservers on 1.5 have been broken since the DAFS merge. And how many complaints have we had? [13:52:46] maybe a dozen [13:52:51] --- deason has left [13:52:53] Yeh. [13:53:00] and they've been only useless (not broken) since 1.5.38 [13:53:30] --- deason has become available [13:54:08] You see, I suspect that in my world, dafs wouldn't even be on 1.5 yet. [13:54:46] well, in retrospect that's probably the right answer [13:54:55] alas, ... [13:55:23] --- abo has left [13:55:26] Hopefully better tools for managing branches, and in particular for fast-forwarding and rebasing those branches, will make keeping things out of tree until they're ready much, much, easier. [13:55:29] --- stevenjenkins has become available [13:56:03] --- abo has become available [13:56:06] well, yes. [13:56:14] e.g. "it's really a shame about cvs" [13:56:28] Yeh. But it's going to die soon, right :) [14:44:56] --- RedBear has become available [15:07:28] mmmm... baking... brownies? :) [15:15:51] chocolate chip and peanut butter cookies. [15:17:02] Cornell Catering had most excellent brownies and cookies at the annual Cornell IT Forum this past week [15:33:00] --- deason has left [15:39:20] --- mmeffie has left [15:40:07] --- deason has become available [16:41:54] --- cclausen has become available [17:16:17] --- Russ has become available [20:27:39] --- cclausen has left: Disconnected [20:29:11] --- cclausen has become available