[02:09:39] --- Stephan Wiesand has become available [06:02:59] --- meffie has become available [06:09:38] --- squinney has become available [06:47:26] --- shadow@gmail.com/barnowl5ABA57FD has left [06:47:35] --- shadow@gmail.com/barnowl5ABA57FD has become available [07:17:15] --- deason/gmail has become available [07:28:39] --- squinney has left [07:37:03] --- meffie has left [08:02:38] [wondering whether Mike and Stephen may return] [08:03:06] Hello. Who's actually watching? [08:03:21] I'm here [08:03:31] Hello Andrew. [08:03:41] *raises hand* [08:03:48] hi [08:03:55] Hi Ben, Hi Simon. [08:03:56] mike probably has issues connecting to the openafs xmpp server from sna, which happens from time to time [08:04:11] Pity. [08:04:30] MIT's XMPP federation seems fragile at times, too. [08:05:07] Does Mike have a gmail account? Could he join us through that? [08:05:59] Let's start. Any input regarding 1.6.2.1? [08:06:07] if he responds to me, we'll see :) [08:06:38] Stephan: I think we should do 1.6.2.1 based on what you currently have tagged [08:07:01] I think we should do a 1.6.2.1 as well; I'm pretty sure I can convince scripts.mit.edu to take it. [08:07:01] Marc seems happy with it, and I'm sure Stephen would be happy to point the latest Fedora builders at it [08:07:16] (scripts runs fedora) [08:07:22] Simon: we don't have any test result except mine. (and it's not tagged yet) [08:08:52] But I can ask Derrick to tag it anytime. I'd just like to have at least one "works for me". [08:09:07] --- meffie has become available [08:09:11] Which SHA1 are you proposing tagging? [08:09:40] one second... it's the one called "make 1.6.2.1" [08:09:41] (sorry for the tardiness) [08:09:48] Hi Mike [08:10:17] 0c411014 [08:10:57] That's what the tarballs were created from. [08:11:17] --- meffie has left [08:11:23] Perhaps directly ask Marc Dionne and Stephen Quinney if they could do a test build of that code? [08:12:09] Ok. Maybe I should ask Ken, too. But they're all reading release-team aren't they? [08:12:50] Anyway, will do. [08:13:45] But I think we're at the point now that if it's good, we do 1.6.2.1. If there are issues, then we should just address them in 1.6.3 [08:14:29] Yes, branching seems hardly reasonable at this point. [08:14:40] Which brings us to 1.6.3. [08:15:32] I've taken more freedom merging changes since Paul is no longer available. Hope everyone is ok with this? [08:16:08] I'm happy... [08:16:12] Seems okay so far. "If you mess up, you'll hear about it eventually" [08:16:14] everything I've seen so far seems fine [08:16:39] Stuff is getting _so_ much more attention than it did in the 1.4 days... [08:16:50] The agenda item was more about what the goals for 1.6.3 are, though? [08:17:03] --- meffie has become available [08:17:24] Yes. The list of changes is still daunting. [08:18:14] I'm wondering whether we should try something like "we'll issue pre1 next week, no matter how much more was merged" [08:18:49] Folks would have a week to push for their favourites. [08:18:56] Doing something time based definitely seems fair. [08:19:01] And a final discussion next wednesday. [08:19:20] To me, issuing a prerelease version is saying that future improvements are cut off and all that will be taken after that is fixes for critical issues with the prerelease version. [08:19:32] Indeed. That would be my understanding of a prerelease. [08:19:40] If you don't make 1.6.3pre1, you're waiting for 1.6.4 [08:19:43] Yes, mine too. [08:19:46] --- Derrick Brashear has become available [08:19:46] Making that cutoff based on a timeline is okay, I just want to make sure we're all on the same page. [08:20:03] If we don't do it on a timeline, you end up with 12 months between releases... [08:20:20] There are certainly many reasonable changes in the queue, but I think there are few critical ones. [08:20:33] Well, I thought there was a propsal to take what's in the queue and nothing more, which is not exactly time-based but still bounded. [08:21:09] But I agree -- I don't remember many critical changes in the queue, so time-based should be fine. [08:21:24] Andrew has been instrumental in pushing most of what's currently queued - he's probably got a feel for how much can wait [08:21:35] But we should be careful we're not just kicking the ball down the road [08:22:22] Will we have 100+ pullups for every release, even if we do manage to get them out timely? [08:22:39] if we get a lot of them this time, no, it won't be like this every time [08:22:56] some of these are from before 1.6.0 [08:23:19] There are currently around 800 coverity errors still outstanding :( [08:23:37] oh. [08:23:37] 800 more?! [08:23:51] that doesn't necessarily mean 800 patches [08:24:03] or 800 actual problems, for that matter [08:24:36] Simon, are those 800 more complicated than the ones we've seen yet? [08:25:39] As we said last time, those "count differently". [08:26:02] The coverity fixes are almost completely merged. [08:26:15] I don't think that's answerable unless simon already has patches for all of them [08:26:17] Yeah - it's not necessarily 800 problems. Coverity reckon on a false positive rate of around 25%. Some projects see nearer to a third [08:27:29] Only about 300 of those are "security sensitive". The rest are what coverity term "quality issues" - so deadlocks, infinite loops, that kind of thing. [08:27:46] --- Derrick Brashear has left: Disconnected [08:27:58] And security sensitive includes things like "using strcpy", "dereferencing a NULL pointer" and so on. [08:30:20] These are all "lightweight" in the sense that it's easy to judge usefulness vs. risk, even for me. [08:30:58] That's different for many of the other changes in the queue. I need help there. [08:31:10] Sure [08:31:35] Thus the "time based" idea. If noone/not many push for a change, it can probably wait. [08:31:37] It sounds like you should send review requests for the ones you want help on, then. [08:31:59] And just push the ones that you are happy with. [08:32:18] Given the number of "simple" changes in the queue, it may not be very efficient to have Simon or Andrew or whoever go through all the candidates. [08:32:21] Ben, I started doing that, and will have to do it more. But they don't always receive attention. [08:32:48] (I could handle some review requests, I think.) [08:33:01] The really simple ones are merged IMO, with a few exceptions. [08:33:05] I should be able to go through all of them; I thought I've already hit most [08:33:34] Exceptions for example: agreed in principle, but some dispute over the commit message. [08:33:56] Or: is the last out of 8 changes touching the same file. [08:35:15] Andrew, yes you have, and thanks a lot. [08:35:53] I think you should feel free to use your authority to override dispute over the commit message, as you see fit. [08:36:15] I don't think those are disputes; just a -1 with 'just change the commit message' [08:36:16] Well, in the acutal cases I agree that it should be changed ;-) [08:36:22] which a reviewer could just fix themselves [08:36:26] or stephan could [08:37:09] I'm still a bit "shy" there. [08:37:37] Not sure how it makes people feel if their pullup is changed this way. [08:38:14] I think people mind less about commit messages, especially since cherry-picked ones are effectively automated [08:38:15] In krb5.git, when we change someone's commit message, we add a note in brackets [kaduk@mit.edu: changed commit message] [08:38:46] you can just say in a gerrit comment.... [08:39:15] 9364 is an example [08:39:16] What are the situations where a pullup should have a different commit message than it has on master? [08:39:49] yeah, and on that one, I can just submit it with the fixed message [08:40:14] deason: Yes please! [08:40:16] 9370/9583 is another one [08:40:22] well 9364, ken agrees. [08:40:24] well, in that example, the cherry pick doesn't have the full commit message from master [08:40:35] there's another one where it's just the message from the wrong commit on master [08:40:36] etc etc [08:41:00] I don't know if it's useful to really go through these, I can just fix the ones that are clear [08:41:09] They all seem pretty clear... [08:41:23] for commit msgs, yeah [08:42:16] Ok, thanks. In the future, I'll fix some myself and bother others to fix others. [08:42:54] And send out more "invitations" to review. [08:43:11] One I'd like to discuss today is 9407. [08:43:27] "remove ih_sync_thread" [08:43:56] So, I am in favour of this in general, but nervous of it in a stable release [08:44:08] Yeah, that. [08:44:13] Simon, that's what I thought. [08:44:19] I'm nervous of _not_ doing this in a stable release [08:45:10] deason: Because of more issues similar to the ones you fixed for 1.6.2 ? [08:45:56] because that thread is a ticking time bomb that's already exploded twice [08:46:18] Sure, understood [08:46:22] I also just don't see what could possibly break by removing it [08:46:30] didn't we include a change defusing it in 1.6.2? [08:46:40] I can agree that something is the right thing to do and still be nervous about it :) [08:46:52] We fixed some of the problems in 1.6.2, but that doesn't mean that we found all of the problems. [08:47:03] Stephan Wiesand: we had also thought it had been fixed before :) [08:47:49] er, what I mean is, before the 1.6.2 stuff, we had the situation where it broke, and a fix was attempted that seemed to fix the specific issue [08:47:53] It's got a pretty good set of +1s, though. [08:48:26] Simon, yes it is. But if you're nervous about it, I still care. [08:48:37] I would be less nervous about it in a release that had fewer other things happening, but it doesn't seem like we're going to have one of those for a while. [08:48:54] (and then it happened again for the 1.6.2 stuff....) [08:49:22] Simon, 1.6.2 can still become such a release. [08:49:51] Lots of coverity/clang + this + very little else. [08:50:06] er, 1.6.3? [08:50:19] sure, 1.6.3. [08:50:27] That's possibly the way to go. I don't think we want to wait for 1.10 in order to ship it. [08:52:15] that does sound like a wise choice. [08:52:52] except, any regression fixes. [08:53:28] Sure. But we'd leave changes from "before 1.6.0" for 1.6.4, for example. [08:54:00] well, what I don't like about that... [08:54:31] is that it seems to prioritize the clang/coverity fixes over fixes for problems that people have actually encountered and reported [08:55:10] but I suppose that doesn't matter for things that haven't raised a ruckus [08:55:30] I would always prioritize changes by their use:risk ratio. [08:55:32] all of them are small simple bugs, so I guess they're not much different [08:56:09] well okay, but a lot of the clang/coverity fixes we don't know if they have any utility (and analyzing them all for impact is probably too much effort) [08:57:40] I dunno, it depends on that what "+ little else" contains :) [08:57:49] yes. [08:57:53] If the denominator is small, the priority becomes high, even if the utility is unknown. [08:58:03] Well, what is it you want to push for? [08:59:44] well, in general I would push for the fixes for reported issues over any of the theoretical stuff [09:00:01] The advantage of fixing the theoretical stuff is that it reduces the noise. [09:00:26] But we're not currently doing any analysis runs over 1.6, so I'm not particularly bothered whether they get pulled up or not. [09:00:58] well, dropping them from the list (whether that means 'accepted' or 'rejected') reduces the noise [09:01:09] assuming you mean noise as in, 'lots of things in the gerrit queue' [09:01:42] No, I mean noise as in "seeing the bug that really is a security hole amongst all of the other issues in this analyser report" [09:02:10] But I'd also like to see fixes for reported issues make it in too. [09:02:13] But the coverity report only goes to what, You, Derrick, and Jeff? [09:02:13] well yeah, but that's just on master [09:02:26] At the moment, just me + gatekeepers [09:02:40] and you can still run the report against a release + 'coverity patches' [09:02:53] (er, I assume) [09:03:06] removing noise doesn't mean they need to be in a release [09:03:30] Well, that's trickier because you have to keep rebasing those patches against each release. And I just don't have time for that. [09:03:45] With my user/admin hat on, I want them in the stable releases. [09:04:26] And from what I'm hearing, the issue isn't the coverity patches, because generally its easy to see whether they are correct or not, but some of the more complex changes for "real" issues. [09:05:21] Even if it fixes a real issue - if it has a high potential to break something it shouldn't go into a stable relase. [09:05:35] all I'm saying is, if you accept coverity patches before the other fixes, you're introducing changes (and thus, bugs) that may or may not fix something actually noticeable [09:06:02] while we are already saturated with fixes that are known to fix something noticeable [09:06:17] but sorry, I didn't mean to make a whole thing about it, I'm not saying anything needs to change [09:06:31] that's just my opinion on it [09:06:40] But if you believe that defects directly correlate to number of modified lines of code, then the coverity changes are inherently lower risk, as they usual just modify a single (or a couple) of lines of code. [09:06:56] It's all about trade-offs :) [09:07:40] Andrew: And it's valued. I still believe in use:risk to decide what goes in. [09:08:30] I don't think it correlates to LoC modified, but even so, if you have 100 changes that modify 2 lines each... [09:09:29] LoC is apparently about the only thing that correlates with defect rate :) [09:09:35] But anyway... [09:09:51] Are there particular changes we're arguing about here in the queue? [09:10:12] I could bring some up I wanted discussed [09:10:32] Stephan has been sending me review requests as we chat here :) [09:10:40] if Stephan's okay with moving on? [09:11:19] Yes, let's discuss a few specific ones. Maybe this will also help getting the policy straight. [09:11:25] How about 9121? [09:11:38] Ben: Thanks for the offer ;-) [09:12:15] So 9121 is interesting. [09:12:18] It's correct [09:12:24] But it will make stuff run much slower [09:12:33] I feel like if that broke anything, it'd be pretty obvious when the server starts up [09:12:41] er, what? because jumbograms are faster? [09:12:48] Yes [09:13:08] Jumbograms are about 3 times faster than non-jumbo [09:13:21] that depends heavily on the environment [09:13:28] Not really [09:13:32] I thought this had already been discussed when jumbograms were turned off by default years ago [09:13:45] since in many environments, turning them on makes things unusably slow [09:13:48] They were turned off by default because there were lots of places where they just plain broke. [09:13:57] so the default is to turn them off, and if you want them on, you can turn them on [09:14:13] Or the RX stack's constant attempts to upgrade to jumbograms would leave throughput at a trickle [09:14:52] But where jumbograms "work" they are significantly faster. [09:15:16] Is there a site that doesn't work without 9121? [09:15:27] yes [09:15:33] well, "doesn't work" is a bit vague [09:15:43] I'm not saying that this means that we shouldn't take this change, but if we do, it should be prominently release noted, so places that notice things running slower can turn jumbo back on. [09:15:46] ubik synchronization goes really slow if you're in an applicable environment [09:16:12] Potentially, it won't work at all. It depends on how the underlying network deals with jumboframes and fragmented UDP. [09:16:44] if they get dropped, we resend with smaller packets [09:17:10] … eventually :) [09:17:34] (Or is it okay in the kernel?) [09:17:43] Whoops, wrong room. [09:17:56] [relieved] [09:18:33] So, take it but make the change prominent? Maybe even in the announcement? [09:18:55] Is it sufficiently orthogonal to the ih_sync_thread removal? [09:19:10] Yes, and yes. [09:19:39] Sounds like it can go in. But I want more +1's ;-) [09:21:06] Thanks :-) [09:21:54] (to be clear, there are other things I want to bring up, but I'll let you go through yours first) [09:22:33] No, go ahead. [09:23:33] 9666 and/or 9667; the solaris 11 krb5 thing that has been mentioned before [09:23:58] I don't know if there's a preference on which of those to take (or if 'both' are okay); from before, I was leaning to just 9666 [09:24:23] which just changes aklog to search /etc/krb5.conf:/etc/krb5/krb5.conf instead of just /etc/krb5.conf [09:25:06] 9666 seems fine to take. [09:25:52] (sorry for no 1.6 version to +1 in gerrit, they were just merged recently... will do soon) [09:25:56] Should the /etc/krb5/krb5.conf be Solaris only? [09:26:10] That would be the safest change [09:26:20] it could be, I wasn't sure if it mattered enough to care [09:26:34] that may be the right path on other platforms; I have no idea [09:27:08] which is the motivation for 9667 since it works more generally, but I didn't know if that seemed too "risk"y for 1.6.3 [09:27:12] The only case I'm thinking about is if someone has two parallel Kerberos implementations installed - if suddenly we start consulting a bogus config file. [09:27:56] yeah, but couldn't /etc/krb5.conf be "bogus", too? [09:28:01] Yeah [09:28:08] The whole thing is just nasty [09:28:20] I like 9667, because it asks administrators to opt in to the nastiness. [09:28:22] Yeah, running parallel kerberos implementations is no fun. [09:28:33] I don't understand why openafs has to care here. [09:28:46] We're the ~last application that requires weak crypto. [09:29:00] Stephan: Because in some versions of MIT they turned off DES, without providing a way for us to ask that it be turned back on [09:29:20] Now that I look at 9667, I think I agree with Simon that it's good. [09:29:31] There's a config file option, but not an API function to call. Heimdal gave us an API function, which MIT later adopted too. [09:30:14] well, there is a way to turn it on, but we need to modify the config file [09:30:20] kaduk: Sadly we're not the last. There's still quite a lot of NFS that's single DES only - and loads of corporate code. [09:30:22] Hmm, now why do I remember not finding the API function in heimdal when I went looking ... maybe it was too old a version. [09:30:44] but obviously instead of modifying the config on the machine, we try to use an alternate config file that just says to turn it back on [09:31:00] but we also need to specify the original 'default' location of the config file, so both are used [09:31:00] The Darwin-specific problem is that the API function exists in Heimdal, but not in the shim that Apple use to make Heimdal look like MIT [09:31:16] if KRB5_CONFIG doesn't have anything in it, we don't know where to look for the default config file [09:31:32] since, afaik, there is no krb5 function to get what the default path is [09:31:35] so, we're guessing [09:31:43] (oh what a mess) [09:31:46] Simon: do you remember which NFS? I feel like there are a bunch, but only know FreeBSD's off the top of my head. [09:32:11] I thought it was every nfs besides recent linux [09:32:50] Anyway, that's off-topic and we should probably not talk about it here. [09:33:05] SO, 9667 it is? [09:33:09] I would be happy with 9666, but only if we take 9667 as well. [09:33:24] well, I can submit both, and we can defer the decision to gerrit [09:33:45] but it sounds like we're okay with "something", which is all I really wanted here :) [09:33:46] moving on...? [09:34:14] sure [09:34:27] ok [09:34:59] 9678/9679 (and possibly 9680); this is the thing andy malato sent to the list about 'vos ex'/listvol reporting changing [09:35:10] I assumed that was okay because it was pretty small and a 1.6 regression [09:36:07] another brand new one...? [09:36:14] that's why I'm bringing these up [09:37:37] I suspect we should defer those, just on grounds of timeliness. The change has been on master for less than a day. [09:38:38] I would be inclined to say, as a rule of thumb, that we should only consider for 1.6.n changes that were on master prior to the release of 1.6.(n-1), unless those changes address a regression between 1.6.(n-1) and 1.6.(n-2) [09:39:23] well, if people ran master, that would be helpful. [09:39:36] Some people do run master... [09:39:41] Simon, I tend to agree. This one also seems to fix a problem introduced in 2009? [09:40:06] it's been around for a while, and just getting noticed as people actually try 1.6 [09:40:28] if you say 'defer' then defer, and we can move on [09:40:46] defer [09:41:29] okay, next; I would like some clarification on what we're doing for the issue in 9588 [09:42:08] if there's not going to be anything in 1.6.3 for it, are we going to do something for, say, 1.6.4 if there's something in the tree? [09:42:24] You mean the thread that only you and I spoke on on afs3-stds? [09:42:31] yes [09:43:06] I can take the time and fix all of the cases, but I'm still not sure if this is "okay", and what timeline we're expecting for it, etc.... [09:43:35] but as derrick mentioned at some point, regardless of what "afs3-stds" thinks, openafs can just put in limits to protect our stuff, at least temporarily [09:43:38] I'm not sure that we can apply hard limits without also creating new RPC variants that take a cursor to allow us to iterate through a list that is above the hard limit [09:44:11] Simon's point is correct. [09:44:23] (I think I mentioned it on-list?) [09:44:33] I don't think I've read those emails... [09:44:36] Hang on... [09:44:47] well, "we can't" based on... "adhering to standards"-ness? or it'll break something? or what? [09:44:51] From my angle: there's nothing on master that has been agreed, and the problem has existed forever. It's not relevant to 1.6.x for the time being. [09:45:02] We are taking configurations that currently work and breaking them. [09:45:12] Now, it's possible that no one is running such configurations, but... [09:45:18] practically speaking, there is nothing in the tree that can issue request that result in the lists being that large [09:45:23] for at least some of those [09:45:30] not sure on all of them, because I haven't gone through them yet [09:45:45] I haven't looked at individual cases, yet. [09:46:07] Perhaps we should discuss the fix for this elsewhere? openafs@ ? [09:46:14] but I mean, iirc for pts stuff, the openafs tooling already has limits in the tools themselves, so we shouldn't break anything [09:46:15] okay okay [09:46:17] moving on [09:47:03] Yeah, there's nothing in master yet, so we should defer for 1.6.3 unless Simon wants to call it a security issue [09:47:15] there's that heimdal krb5-config thing mans nillson posted about; is that not possible for 1.6.3 relevance if we did something about it? (I believe it's just a buildsystem change) [09:47:28] There are lots of other ways of using up all of the resources on one of our servers. [09:47:42] I don't remember the heimdal krb5-config thing off-hand, let me find it [09:48:02] I think someone just said we needed to upgrade the version of the rra krb5 autoconf logic [09:48:06] There's a couple of problems [09:48:18] Our version of the files pulled from rra-c-util is too old on 1.6 [09:48:34] And we don't make use of the KRB5_CPPFLAGS, and KRB5_LDFLAGS that it gives us [09:48:50] But changing to a newer version of rra-c-util means that KRB5_CONFIG becomes PATH_KRB5_CONFIG [09:50:10] aside from changing KRB5_CONFIG -> PATH_KRB5_CONFIG, I assume it's fine as far as "it's a new change" goes, because it's platform support and only affects builds... am I way off? [09:50:33] I'd be happy with everything there apart from the last bit. [09:50:55] > everything there Er, where? [09:50:56] I think it just needs someone who builds 1.6 against Heimdal to propose a set of changes. [09:51:03] we could possibly alter it so we keep using KRB5_CONFIG, but, I mean, I get why that was changed [09:51:11] Andrew, no you aren't way off. [09:51:31] Yeah, I do too. I just don't want to change our build logic mid-way through a stable series. That's the kind of thing that just makes people grumpy. [09:51:46] Indeed. [09:51:58] What are the relevant heimdal version(s)? [09:52:29] I don't actually know. It may also depend on how your Heimdal is built (I think the problem only arises if it is installed in a non-standard location) [09:53:06] Well, it was a --deps issue. But I didn't read super-closely. [09:53:16] the way russ talked about it on list, it wasn't a specific version but just that he was using heimdal on solaris, so in a 'weird' location [09:53:24] er at least, that's just the impression I got [09:53:35] but I can build myself and see what happens [09:53:36] I run heimdal 1.5.2 on freebsd, but it's at a standard location. [09:53:55] what I've gathered here is that we'd be okay with fixing that, as long as KRB5_CONFIG doesn't change? [09:54:05] and making KRB5_CONFIG not change is... decided? or still up for debate? [09:54:51] Yeah, I'm happy with that. [09:55:12] I think making KRB5_CONFIG not change is decided. [09:55:36] I think the best way to do it is probably to pull the new rra-c-util up from master, and then have a second change that reverts the variable name. That way, we should get conflicts with any subsequent pullup, and remember why its done that way. [09:55:52] I'd like to hear russ's thoughts on that sometime, but for now I'll assume not changing [09:56:03] Simon's plan sounds good. [09:56:12] yeah, that's what I was assuming [09:56:26] I think Russ is reading zephyr at the moment; should I proxy? [09:57:05] sure, if you want to, but we're not blocked on a response for the meeting here, I think [09:57:12] so I think we can move on [09:58:06] Fine. Just figure it out ;-) [09:58:17] I think that's all I had [09:58:37] I have one: 9280 [09:59:18] I think I'll +1 that when I get to the review request. [09:59:36] On it's way. [10:00:10] I'd like to hear whether Stephan wants us to look for a replacement for Paul. [10:00:12] I think 9279 was agreed already. But I understand 9280 must go with it, and that now asserts? [10:00:14] --- rra has become available [10:00:20] 9280 is fine [10:00:40] If we ever hit that assert we're in real trouble... [10:00:48] hi russ [10:01:09] Ok, thanks. That's one I had sent out invitations for and got no response. [10:01:16] Hello Russ. [10:01:16] kaduk: did you explain what's going on, or did you just say "hey come in here"? :) [10:01:34] The specific problem with Heimdal is that new versions of Heimdal only give you libkrb5 when you do krb5-config --libs krb5 unless you add --deps. [10:01:37] I sent Simon's plan and the request for comment, and a link to logs. [10:01:50] How new of Heimdal? [10:01:53] But the Kerberos code in the OpenAFS tree makes direct calls into the underlying library because we do weird shit. [10:02:22] That's a good question. Derrick, do you remember when you started running into this? You were the first person to report the problem to me. [10:02:28] I want to say 1.3 or so, but I'm not sure. [10:02:35] derrick's not watching, I don't think [10:02:38] Derrick's not really here, sadly. [10:02:39] Oh, okay. [10:02:44] but the specific problem I don't think is the issue [10:02:54] Pulling up new rra-c-util will definitely fix that problem. [10:02:56] we're fine with fixing that, but the problem brought up was the KRB5_CONFIG -> PATH_KRB5_CONFIG change [10:03:07] I think there's also a problem that we don't actually use half of the information we get back - so ignore CPPFLAGS and LDFLAGS, which is another part of the problem. [10:03:24] Right, that change was at the request of Sam Hartman because KRB5_CONFIG is, of course, used to find krb5.conf, and if you have it already set for other reasons and try to build OpenAFS, you get very unhappy. [10:03:25] Yeah, what we're planning is pulling up a new rra-c-util, but reverting back to using KRB5_CONFIG [10:03:38] Because Autoconf tries to execute your krb5.conf file. [10:03:48] yeah, I understand why it was done and I agree with that, but changing that in the middle of a stable release series...? [10:04:07] do you agree/disagree with keeping it as KRB5_CONFIG? [10:04:15] Well, it only affects people building from source who need to override the krb5-config path, so we're talking about a small but non-zero population. [10:04:31] Personally, I'd just change it to PATH_KRB5_CONFIG and say so in NEWS, but I don't object to changing it either. [10:04:40] Er, reverting back to KRB5_CONFIG, I mean. [10:05:48] okay, current decision was keeping KRB5_CONFIG, I just wanted your thoughts if you disagreed [10:05:56] Could someone summarize for me, once appropriate? [10:07:00] we'll upgrade the krb5 autoconf logic to fix the issues with using heimdal, but we will keep using KRB5_CONFIG as the variable to point to krb5-config [10:07:01] I guess I mildly disagree in that it feels too conservative to me, but I don't think it's a big deal eithre way, and certainly don't mind if you keep KRB5_CONFIG. [10:07:31] Shall we do what deason outlines for now, and if necessary we can discuss it further once we've got code to look at. [10:07:37] alright [10:07:48] so, moving on? I think 9280 discussion was done, too? [10:07:52] > we But who? [10:08:01] heimdal krb5 whatever, I'll do [10:08:22] Andrew said "but I can build myself and see what happens" [10:08:23] 9280 was done. +1s are trickling in :) [10:08:26] I guess the agenda also mentioned snapdhots but I'm not clear what that meant. [10:09:10] It meant we now have merged some 60+ changes. Would it make sense to provide "pre0" tarballs to release-team for smoke testing? [10:09:39] Ah. [10:10:03] I don't think that release-team has a particular barrier to building from git. [10:10:08] in theory I thought release-team people were saturated with reviewing and pulling changes :) [10:10:09] I think we should probably wait until we are closer to being done. We don't want to burn out release-team [10:10:14] (i would build from git) [10:10:38] It was just an idea. So let's forget it. [10:11:18] Okay. [10:11:26] Ben asked a question... trying to find it in the scrollback... [10:11:29] What I would like to suggest is that we pick a date to close openafs-stable-1_6_x to new patches [10:12:05] Next thursday 5pm utc. [10:12:06] Stephan: "Do you want a Paul 2.0?" [10:12:26] I feel like snapshots may be useful to some of the release-team list members that are not here... but if it's too early, then yeah, nevermind [10:12:40] "we can rebuild him" [10:12:53] We could do a snapshot next week after we close, and call that pre1 :) [10:12:56] Andrew, It's close to 0 work to create them. [10:13:07] Ben: Nice idea. [10:13:17] Well, I think there's when we close the queue to new entries, and then how long we allow it to drain for ... [10:13:22] I think the concern was more the work for people to 'look at' the snapshots [10:13:49] Regarding Paul: I certainly am not happy that he left. [10:14:14] do we need a 2nd person though? [10:14:30] I don't know if Stephan feels overwhelmed, but I thought he's been doing fine [10:14:30] [snapshots: I'll send minutes - maybe there will be feedback] [10:15:13] I'm not keen on doing it alone. I think there's no hurry to find a replacement either. [10:15:20] I guess you are a single point of failure, though [10:15:46] but also, have a single person means the buck stops here. [10:15:57] No, I can be replaced by quite a few of you anytime, if required. [10:16:37] "the buck stops here"? sorry for being stupid... [10:16:51] an idiom [10:16:54] Not without pulling us away from other things :) And I think having someone passing judgement on changes who hasn't written them, or doesn't have a client demanding they be in the next release is a good thing. [10:17:57] it means... um, um, um, well, he just means if people are wishy-washy about decisions or whatever, having a single person makes it easier for someone to put their foot down and just decide [10:17:59] (oh, sorry, yes, an american idiom. one person to make the final decisions) [10:18:07] I suppose I just tried to explain that using another idiom, though [10:18:21]