[05:47:39] --- meffie has become available [05:57:28] --- meffie has left [05:58:06] --- mmeffie has become available [05:59:48] --- mmeffie is now known as meffie [06:03:18] --- Stephan Wiesand has become available [06:47:12] --- paul.smeddle has become available [06:52:15] Good morning/afternoon [06:52:59] Hi Paul [06:53:41] 'mornin'. [06:53:55] good day [06:54:25] Hey Stephan, Benjamin, Mike [06:59:16] --- haba has become available [07:00:23] Harald, thanks for your input regarding Fedora. [07:02:36] Who has topics for the agenda? [07:04:10] Nobody? Let me try: [07:04:18] Hi Stephan, that were just some random thoughts between changing diapers. Sorry, no more topics in my head. [07:04:43] topic: Fedora release? [07:04:58] topic: 1.6.3 time frame [07:05:08] topic: Windows status? [07:05:24] topic: New kernel which is related to fedora release [07:05:47] and, of course, changes to be merged [07:06:25] I think windows on 1.6 is dead [07:06:45] That's a statement. Thanks. [07:06:59] --- deason has become available [07:07:12] All flavours of Windows? [07:07:28] 32 AND 64 bit? [07:07:44] cuz beyond that there's one flavor. the build you get [07:08:07] let me describe my analysis of the situation. [07:09:03] Or let me ask the other way around: Are there any windows flavours where you can not use 1.7 ? [07:09:26] topic: 3216/2984 (and... are we going through to yay/nay all of the pending 1.6 patches?) [07:11:06] i have a list of patches on master, which i grouped by subject. [07:11:15] Well, if we're not going to do "official" point releases of 1.6.2, the timeline should be ~ 2 months. [07:11:37] at the moment there is only one volunteer developer of windows which is me. Peter Scott and Rod Widdowson do work on the windows client when I hire them to do so. At the present time there is no one with time available to do work to support windows on 1.6. Beyond that, the smb interface provided by 1.6 does not work on either windows 7 or windows 8. It does work on Windows 2000 through Vista and the matching server platforms but has all of the limitations of that interface including smb redirector kernel deadlocks, etc. The only platform that 1.7 does not support is Windows 2000. [07:11:57] my take as to point release is it's not a horrible idea, and we've done it before. but *only* platform support, and nothing else. [07:12:31] if you still have windows 2000, you get to run something old. you already are. [07:12:42] that is my take [07:13:35] (platform, or a security point release, iirc) [07:13:54] sure [07:14:28] one change for F18 is linked into the dependency chain of the coverity fixes [07:14:50] i bet you can merge it out of order [07:14:54] if not, rebase it, then merge [07:15:13] gerrit doesn't check? [07:15:13] On the subject of point releases. We have done them in the past to support platform specific updates for OSX and Windows. I see no reason why doing so for linux 3.8 should be out of the question. The release would only have linux binaries and would only include the minimum set of patches to permit support for 3.8 [07:15:14] In that case ist seems reasonable that 1.6 is no longer for Windows and if someone wants 1.6 on W-2000 then that person can run something old. [07:16:15] gerrit actually tries the merge, and tells you if it worked or not. if there are path conflicts, the merge will fail. same as if you git cherry-pick it yourself. [07:16:34] no path conflict, so no problem. [07:16:39] e.g. openafs gerrit runs in cherry-pick mode, so same rules apply [07:16:49] yeah. so. not an actual problem. [07:17:05] cherry-pick should try to merge harder than gerrit these days, I thought; it's not quite the same [07:17:50] it's the init script thing - I don't think any other change in the pipeline touches that. [07:19:07] So, do 1.6.2.1 for F18+? (and other Linux 3.8 users) [07:19:28] sure. but for the purpose of this discussion, the takeaway is "try it" [07:19:45] nothing else touches afs.rc.linux, no [07:19:51] so you should be golden. [07:20:25] --- ktdreyer has become available [07:21:21] Hi Ken [07:21:25] (sorry I'm late) [07:21:35] Another idea: Could we make a relatively conservative 1.6.3pre1, and say that's for F18+/3.8? [07:22:11] Like, the 3.8 + openafs.rc + coverity series? [07:22:14] will it hurt anyone who needs a "release version"? [07:22:22] that's only debian, right, and they are already patching [07:22:33] That doesn't feel like a standard use of a prerelease moniker. [07:22:34] everyone else is rpm and will just build what they have? [07:22:48] it sounds to me like it would work, though [07:22:59] it's not, but since it hasn't gone through all the testing of other stuff, it's not unfair to call it that [07:23:03] fedora wants "bleeding" or whatever, that's a way to get it to them from our perspective [07:23:09] I think saying that 3.8pre1 is stable for 3.8 kernels is going to be troublesome. [07:23:16] I think Debian can deal with a tagged version, even if it is named as a prerelease. [07:23:24] when i want bleeding i just start peeling vegetables. [07:23:25] Eh, FC18 folks will probably just take the 1.6.3pre* and will be happy [07:24:11] well. if russ turns out to need a tag, you could declare it 1.6.2.1 or something. but otherwise, who cares? [07:24:36] The question is if we want them rather to test a 1.6.3pre or a 1.6.2.1 [07:24:54] people will probably assume 1.6.2.1 was tested by someone else [07:25:11] I think 3.8 patches should be committed, it should be tagged 1.6.2.1 and 1.6.3pre1 should be what we think 1.6.3 should look like at this point. [07:25:14] If it's called 1.6.2.1, it should be well tested. Do we want to spend that effort? [07:26:12] Stephan has a point. For the 1.6.3pre [07:26:25] A presumptive 1.6.2.1 would only need to be tested on Fedora (or perhaps linux26), though, right? [07:26:58] Jeff, merging 50 changes and several features in two steps is not necessarily a bad idea, I think. [07:26:59] speaking as a Fedora packager: Fedora users can either use the RPMs that I manage, or else cherry-pick their own patches from Git/Gerrit. There are multiple options, and neither have to involve spending the resources of the release team [07:27:14] just wondering, does anyone here even have fc18 ready for testing? (I assume ken?) [07:28:15] my perspective is that we don't have the resources to chase Fedora's kernels, and we should just take two months and make 1.6.3 polished [07:28:43] I mean, 3.9 will come soon, and do we keep doing this forever? I don't think it's sustainable [07:29:02] well, I think it's possible to keep doing, but it doesn't seem worth it, to me [07:30:13] Ken, I agree. You're not completely unbiased though ;-) [07:30:48] Jeff: Do you think making first pre1 and then pre2 and then pre3 and between them merging a subset of the patches we think should be in 1.6.3 is a bad idea? [07:31:33] I mean one feature at the time [07:32:40] I would not suggest that OpenAFS change Fedora kernel releases. However, this happens to be a convenient time to do a 1.6.2.1 that matches FC18. It wouldn't be a lot of work to do so as an incremental step towards 1.6.3pre1 so it is reasonable to consider it. When FC19 is ready with kernel 3.9 in a month it will not be appropriate to issue a step release. [07:34:15] I'm of the opinion they can have an early pre which is aimed at supporting 3.8, rather than another release. [07:34:17] For each pre release we need to wait at least a week maybe two to obtain feedback. Each pre-release is a test burden on the limited number of community members that do test. We should strive to reduce the number of pre-releases. 1.6 is a stable (aka maintenance) branch. It is not supposed to have new features. [07:35:47] We haven't merged anything yet after 1.6.2, thus we don't have to branch. But this will change soon, so we have to make up our mind now. [07:36:31] We sure included features in 1.6.2. [07:36:40] I'm of a similar mind to Jeff; it doesn't seem like we should call something a 1.6.3 prerelease if we know that it doesn't actually look like what 1.6.3 will be. [07:36:41] In the end the decision to release a 1.6.2.1 is up to Paul and Stephan. I agree once a patch that is not appropriate for 1.6.2.1 hits the openafs-stable-1_6_x branch the option to release 1.6.2.1 is gone. [07:38:19] well, can't we just make a pre1 with what we think 1.6.3 will look like, and fc18 can use that? that would be faster than them just waiting for 1.6.3 itself, which was one of the possibilities mentioned on list [07:38:26] You could take the approach of pushing just the 3.8 patches first and letting folks that care go off and test just those patches on various platforms and tag later if it is determined that everything is ok. [07:39:35] the risk of taking the only issue pre1 approach is that a bug creeps in to 1.6.3pre1 and it bites someone that wants a stable release. [07:39:47] jeff: yes. we can even merge a "make 1.6.2.1", even if we don't use it. [07:39:57] correct [07:41:00] jeff: yes again. If we merge everything sitting in gerrit now, don't think we should recommend using that before thorough testing. [07:41:28] Which boils down to: How big is the chance of such a bite from the patches that we want in 1.6.3 but are not patches for the 3.8 kernel. [07:41:30] if someone wants a stable release, I think they already lost by running a recent linux kernel, but maybe that's just me [07:41:58] +1 to that [07:41:59] right, so first merge 3.8 patches, get some testing, merge a make 1.6.2.1 commit, just to have it if we want to make a release [07:42:24] Paul, ok. [07:42:26] Sounds like a plan. [07:42:39] At least we don't have to take a decision today then :-/ [07:42:48] Paul: Right, then someone can pull out a 1.6.2.1 if "desperate". [07:43:17] So what's the list of patches? It's not quite as clear to me as Simon claimed it should be... [07:43:53] But I hope it is to Ken. [07:44:18] the 3.8 patches? [07:44:19] ...list of patches for 3.8? [07:44:38] didn't ken summarize it in email? [07:45:26] In Ken's email was: http://gerrit.openafs.org/8941 http://gerrit.openafs.org/8942 http://gerrit.openafs.org/8948 http://gerrit.openafs.org/9334 [07:45:31] I came to find out my email was actually off, because some of them had already been proposed, etc. Mark and Derrick helped straighten me out in Gerrit. I could send a followup email on that thread [07:46:45] just a minute I'll look up the right ones [07:48:25] so, in theory the only ones we *strictly* need are Linux-3.8-session_keyring-changes: http://gerrit.openafs.org/8941 Linux-3.8-vmtruncate-removal: http://gerrit.openafs.org/8942 [07:48:55] however, it would be nice to have 'Fix "aklog -setpag" on Linux 3.8' http://gerrit.openafs.org/8948 , and 'Watch for undefined symbols in the future' http://gerrit.openafs.org/9364 and http://gerrit.openafs.org/9365 [07:49:32] (s/Mark/Marc/) [07:49:54] sorry, Marc, you're right [07:50:10] and 9363? [07:50:11] I assumed we'd be including all of those [07:51:22] that one seems like a good idea, too; I assume the init script bails out without that [07:52:06] On F18, one should probably rather use the systemd unit file. But yes. [07:52:18] ah, yeah the reason I didn't pay much attention to that one is I think systemd is in effect for F18 [07:52:33] ah, okay; when does the init script get used, then? [07:52:44] So it's 8941/2/8 + 9393/4/5 ? [07:53:18] just when the user explicitly says "I don't want systemd?" (I assume that's rare, but I don't see that as a reason to not include it) [07:53:49] I don't know of a way to turn it off like that [07:54:28] You can still mask the unit file and use the init scripts as for the past decades. [07:55:04] there you go [07:55:17] If you look at afs.rc.linux, do the lines 86-92 make sense to you? [07:56:26] Stephan Wiesand: itym 8941/2/8 + 9363/4/5 ? [07:56:56] Andrew: yes, thanks. [07:57:38] harald, that we check for no addresses 2 different ways? [07:57:45] The 1.6.2 RPMs for 1.6.2 from Edinburgh ship a unit file, no init script. [07:57:51] Ok, I see, that's not broken, just bad sh style [07:58:07] It could affect other distros though, and the change is harmless. [07:58:45] --- paul.smeddle has left: release-team [07:59:04] if afs is running with -dynroot, we don't need an IP, right? [07:59:10] --- paul.smeddle has become available [07:59:55] Paul, are you ok with merging 8941/2/8 + 9363/4/5 and then a make 1.6..2.1? [07:59:55] nevermind, looks like they check for it above on line 279 [08:00:01] well, hence: if [ `echo "$OPTIONS" | grep -c dynroot` = 0 ]; then on_network || exit 1 fi [08:02:07] right, sorry, missed it :) [08:02:53] While Paul is probably looking at those... I was hoping we could agree on all the coverity fixes in go. [08:03:45] i'll look through and see if there are any more which should go. possibly a few more [08:04:56] I can ask Chas about 9363 in the Gerrit comments [08:07:24] Stephan: yes, but I think we should do a smoke test of the head of the branch before a make 1.6.2.1 commit [08:09:19] Paul, fine. The make 1.6.2.1 isn't critical, just that we don't merge anything unrelated after it before testing is done. [08:09:45] yep [08:10:02] So here's our first delay of 1.6.3... [08:10:21] But ok, let's do it like that. [08:10:22] smoke testing 1.6.2.1? [08:10:41] realize… you can just branch it once you pull those patches in, and keep merging [08:10:48] if you think nothing else will be needed. [08:11:25] My time is up for today, gotta run som errands. [08:11:28] (in fact that number scheme implies a branch, to me at least) [08:11:40] Thanks, Harald. Bye. [08:12:00] --- haba has left [08:12:42] No need for a branch, if it's really ready at that point. [08:14:02] I think Jeff would prefer all releases to be on -stable-1_6_x . [08:14:16] yes, that would be better [08:15:01] Ok, so let's try. Back to the coverity class of fixes? [08:15:58] I'm still hoping we can reach some kind of blanket agreement on those. [08:16:17] how about specific objections? [08:16:43] unless I have a list of what changes we're talking about, I don't have any meaningful input [08:16:49] Wouldn't we then need a list of candidates to object to? [08:16:53] If there are some, we'll of course have to take them into account. [08:17:38] The list is so long, we won't get through it today. [08:17:40] http://gerrit.openafs.org/#q,status:open+project:openafs+branch:openafs-stable-1_6_x,n,z everything from march 4 or newer seems like a fine list? [08:18:27] That includes a new feature. [08:18:35] (flushall) [08:18:51] that's an objection, so, there ya go :) [08:19:10] And it will change every time anyone comments. [08:19:45] if we're talking about 1.6.3, I'm hoping to get 9019 tested at my site soon. We're running with it in production, just haven't had a chance to test convertROtoRW with it yet [08:19:49] fs flushall is a new feature, or you could say it fixes a bug, because it is missing on unix :) [08:20:28] how about this? people that have objections should spend the next week reviewing the pending commits in Gerrit and -1 them before next week. [08:20:30] Mike, I want it badly. But we should discuss it separate from those other fixes. [08:20:49] ok, thanks. [08:21:00] fs flushall was a windows only feature because cache sizes cannot be set to 0 to clear the cache on windows [08:21:01] Stephan, I want it badly too ... [08:21:24] Jeff: good plan [08:21:45] I think for, like, strategic direction, the coverity fixes are fine, if I'm interpreting correctly. but for individual review, we'll just wait for next week, when people have a chance to review and -1 [08:22:23] Ok, but will slow us down. [08:22:35] but we can still discuss other "topics" of changes if they should go in here, separate from specific objections that can be raised in gerrit [08:23:04] is that what we're doing here? I'm not telling, but asking [08:23:08] How about Paul & I merge those that we feel are ok and had sufficient positive review in gerrit? [08:23:15] can topics be set on things that dont already have one, if you want group patches for discussion? [08:23:28] gerrit topics i mean [08:23:33] stephan, i like that plan [08:23:35] you need to repush them [08:23:35] if you see those that seem trivial, okay [08:24:32] I like those topics. Please use this feature for future pushes where applicable. [08:25:12] "this feature" == gerrit topics? [08:25:26] Andrew, yes. [08:25:35] I didn't mean to say that, but that works; do you want existing ones re-pushed to have those, where appropriate? [08:26:10] No. [08:27:32] i can coverity topic any new pushes [08:28:23] okay, are we still yay/nay'ing things for this meeting? [08:28:55] Well, Paul & I already yayed fs flushall :-) [08:29:22] But of course I;'d like to have expert feedback on those changes. [08:29:45] Do we want to merge the butc fix I made that is a static-checker sort of thing? [08:30:14] number? [08:30:30] (9140) [08:31:26] Not before it's pushed to 1_6_x for review... [08:31:47] I'd say just push it to 1.6; it can be reviewed next week if it hasn't gotten enough review in gerrit by then [08:32:04] Well, I would not have cared but that we were discussing all these other coverity things. [08:32:31] looking at what's submitted in 1_6_x... is the prevailing opinion on GUACB still that it can go in, but onlf if it has an option but is off by default? [08:32:34] Ben, it should be included in my opinion since it leaks stack state on the wire [08:32:34] 9140 +1 [08:33:12] Okay, pushing the cherry-pick... [08:33:58] I'm ok with 9140, or what it will be for 1.6 [08:34:59] GUACB - yes, that's my point of view [08:35:37] The 9140 cherry-pick is 9404 [08:35:41] yeahm 9140 looks good [08:35:54] or 9404 [08:37:11] GUACB - but there's no such code yet, is there? [08:37:21] as far as I know, correct [08:37:33] Then it's 1.6.4 fodder IMHO. [08:38:16] should we talk about 6266 &co? I think most other things I'm seeing are pretty clearly just bug fixes [08:38:54] 6266 is about the only thing other than guacb which is "feature" [08:39:03] not even its predecessor. just it. [08:40:12] Well, it's not ready for merging. [08:41:07] I can spend the time to get it merge-able, but I'm not clear on how desired it is [08:41:18] (i.e. if I would be wasting my time doing so) [08:41:44] I think you need to make a case for it if you want it to go in. [08:41:54] the question is whether people consider it a feature and thus it should stay out [08:41:59] thus "if" it... [08:42:04] I'm not advocating for it going in; I don't think I feel strongly either way [08:42:16] Sounds like it's not going in, then... [08:42:24] your own comments indicate that the patch has not been tested for dafs and has not seen production use in that configuration. [08:42:31] Why is it in master? [08:42:40] I mean, it's useful, and using that "fixes" a case that's otherwise impossible or difficult to fix, but [08:43:18] because a site uses it; the master submission is a port from a 1.4 patch [08:43:51] for sna, it would be nice to have it in a release, but for this case it's not really critical since it's just one of a bunch of extra patches [08:43:57] let me put it a different way. your employer has clients that are currently using this feature with private forks of 1.4.x. If your employer's clients want to migrate to 1.6.x and need this feature, you as a representative of your employer should make a case for it. [08:44:38] (and i think that's a reasonable thing to do) [08:45:25] for their specific environment, it's obvious, since there this functionality is critical [08:45:46] but for most other places it is not as critical, so I have to weigh that against the possibility that it breaks things for all of the other sites [08:46:00] If it's useful and low-risk, I'm ok with limited amounts of such changes in 1.6 releases. [08:46:00] holistically in my head, it comes out at about equal [08:46:26] I'm not sure about low-risk; it does involve nontrivial changes to volume internals [08:46:37] (I'm not speaking for Paul) [08:46:57] if you are not prepared to distribute this change to all of your employer's supported clients, then I'm not comfortable having it in 1.6.x [08:48:17] see, it's difficult for me to make a case about it [08:48:41] because in my opinion features don't go in 1.6, and in my opinion this is a feature; but this opinion seems different from many others, considering the number of features that go into 1.6 [08:48:44] I think you have made the decision that it does not belong in 1.6 [08:49:04] so, in my ideal world, 1.6 would not gain features, but it does [08:49:19] so I'm not sure if I'm arguing for my ideal 1.6, or whether to argue for the 1.6 that I think actually exists [08:49:42] compared to other things added to 1.6, I think this is comparable and not significantly greater risk [08:49:53] but I also think this shouldn't go in, and neither should many other things [08:50:34] that is irrelevant to the discussion of this change. you are argued there is substantial risk for this change in a broad class of use cases due to lack of testing and you have no volunteered to do the testing necessary to mitigate the risk. [08:50:46] If you have a list of those things, or just examples, please mail it. [08:51:09] I think that's very relevant to the discussion [08:51:15] because introducing this will introduce a bit of risk [08:51:17] but we're already doing that [08:51:34] so I don't think introducing this introduces significantly _more_ [08:51:36] but you have to make a case for introducing that risk and you have refused to do so [08:51:38] that is, it doesn't make things worse [08:51:55] My personal conclusion at this point is that it's not for 1.6.3. [08:52:15] I'm not refusing to do so; I'm asking at what direction I should be coming from for it [08:52:43] are you asking me to explain what this solves? (and the impact, severity, etc) [08:52:56] you should be speaking from the position as the representative of all of the end user organizations your employer represents [08:53:20] i think that's a broad request to make [08:53:40] are you comfortable with this change such that Paul should deploy it tomorrow throughout his organization if he is not already doing so? [08:53:51] are you comfortable with Stephan doing so? [08:54:14] hence my question about your other clients [08:54:32] as I've been saying, the current answer to that is "no", but my answer is also "no" to other things in 1.6, so I don't think that is an accurate measure of what should go into 1.6 [08:54:33] you wrote this change for one client with a specific environment that you have not offered to describe [08:54:53] the difference being that others are prepared to make the case for the other changes [08:56:22] that doesn't change the fact that I don't advocate for them being there [08:56:26] let me try a different way [08:56:45] say, there is a feature that I say shouldn't go in 1.6 and you say it should [08:56:59] for a change that you introduced, you advocate for it being included, I advocate against it, and it goes in [08:57:03] but say I introduce the change [08:57:23] and if the same thing happens, it would go in [08:57:27] he's saying he doesn't feel a strong case can be made by him that it should go in, given how he feels 1.6 should work. i think that's fine, and we can sit on it or wait until someone else clamors for it [08:57:43] I think what I'm saying is, I don't think it should go in, but I think others think it should [08:57:56] then those others should make a case for it. [08:58:01] so if someone else wants it... [08:58:01] okay [08:58:05] right. [08:58:09] hearing none... [08:58:11] but there are no "others" asking for it [08:58:24] well. i considered asking for it. [08:58:29] but i am not at this time. [08:58:31] well, not here; I'm not sure if it's clear what it is [08:59:19] all of those times when someone says they're waiting for a fileserver to break callbacks to shut down, and I say "the fileserver doesn't break callbacks on shutdown", could be experiencing the issue solved by this [08:59:22] er, just mentioning [08:59:46] okay, I assume that's all on this for now, though, sorry to have that take so much time [08:59:59] Restarted all fileservers today. No delays :-) [09:00:02] I think the end result, unless we hear something else, is, not for 1.6.3, but possibily revisit-able for 1.6.4? [09:00:35] Yes. Not for 1.6.3, but no request to abandon it either. [09:00:39] you can build a case for it by discussing the patch on openafs-info at which point some other member of the release team might indicate a desire to test the patch and request it for a future release. [09:00:55] i don't think we care about that today. [09:01:32] Is anyone planning to ask for inclusion of anything not yet in gerrit for 1.6? [09:01:41] discussion on openafs-info to build demand indicates its not a 1.6.3 item in my opinion [09:01:52] I was wondering about 8797 [09:01:58] possibly a couple things pending merge to master from coverity [09:02:23] if there is going to be a lot of arguing about 8797, I'm not going to bother, but I would like to see it [09:02:24] i have some things on master that we discussed during the 1.6.2 cycle, and pushed to 1.6.3 (or later). [09:02:32] (I can submit it and we can discuss later, if you want) [09:02:40] Um there was the budb compile_et thing, let me pull up the number. [09:02:42] i'll just mail a list to release-team, since time is short. [09:02:52] i'd be fine seeing ih_sync_all die in 1.6 [09:03:03] I would be fine with it as well [09:03:14] i read the code to confirm why i believed it was safe was true when we merged it to master (and i think we discussed it here) [09:05:27] ooh, I want 8797 [09:05:39] budb thing is 4027 [09:05:42] You can take that as a client endorsement Andrew :-) [09:05:50] heh [09:05:55] Whatever should go into 1.6.3 should really be in gerrit for 1.6 by next week's meeting. [09:06:20] ideally, by the weekend so people can review, and we should review it before the meeting [09:06:20] (I have not checked that it cherry-picks cleanly) [09:06:21] ok [09:06:50] I may have some things flagged from master, too... should they just be submitted if they're small? [09:07:00] not e.g. just referenced on release-team [09:07:43] I, personally, would like to have them pushed for our branch. [09:07:44] isn't there an outstanding parallel build issue, too? (derrick, whatever the gerrit was that failed on build...?) [09:07:44] I think so; we're really early in the release cycle [09:08:03] is there anything that could possibly fix that, or does that need to be looked into? [09:08:06] there have been several that failed recently. [09:08:24] i think we might have a pending pullup. [09:09:49] (need to run, thank you all.) [09:09:53] Regarding the release cycle: What's our plan? I think we should strive for having pre1 tarballs next Friday. [09:10:01] Thanks Mike. Bye. [09:10:05] bye Mike, thanks [09:10:10] --- meffie has left [09:10:28] Too aggressive? [09:10:45] if you go the merges during/after the release meeting next week we can tag immediately, if nothing else crops up [09:10:55] sounds reasonable [09:10:55] it sounds possible if we have nothing controversial, and stuff actually gets submitted/reviewed by next meeting [09:11:00] but a week from friday seems makeable. [09:11:15] and I don't think we have anything controversial, after the decisions today [09:11:34] 4027 pullup --> 9405 [09:13:23] Thanks. [09:14:22] I think we're on track now? [09:14:26] i think so [09:15:07] awesome [09:15:16] Any volunteer for writing minutes? [09:16:03] sure, I can do that [09:16:10] apparently it was 135 minutes. just write a for loop in perl and it should be able to spit out all 135. er, 136 now. :) [09:16:20] anyway, i gotta go see a man about a brick [09:16:22] --- Derrick Brashear has left [09:16:36] thanks Ken [09:16:41] Thanks Ken. [09:16:43] welll, until next week then [09:17:04] And thanks everyone! I'll be out of here now, too. [09:17:09] ah, the ol see a man about a brick excuse [09:17:13] ;) [09:17:32] --- Stephan Wiesand has left [09:53:35] --- stephan.wiesand has become available [10:18:57] --- Derrick Brashear has become available [10:43:43] --- Derrick Brashear has left [11:07:38] --- meffie has become available [11:42:37] --- kaduk@mit.edu/barnowl has left [11:43:46] --- kaduk@mit.edu/barnowl has become available [11:46:18] --- meffie has left [12:39:03] --- stephan.wiesand has left [12:43:16] --- Derrick Brashear has become available [13:22:17] --- Derrick Brashear has left [13:22:39] --- Derrick Brashear has become available [14:46:22] --- Derrick Brashear has left [17:59:00] --- deason has left [19:03:54] --- Derrick Brashear has become available