[00:12:48] --- stephan.wiesand has become available
[00:12:58] <stephan.wiesand> test...
[00:52:25] --- stephan.wiesand has left
[05:22:21] --- meffie has left
[05:40:19] --- stephan.wiesand has become available
[05:49:40] --- meffie has become available
[07:00:29] <stephan.wiesand> Hello crowd
[07:03:25] --- deason has become available
[07:03:30] --- Marc Dionne has become available
[07:03:35] <deason> hi!
[07:03:41] <Marc Dionne> howdy
[07:03:53] <stephan.wiesand> Hi Andrew & Marc, thanks for joining
[07:04:17] <meffie> morning
[07:04:25] <stephan.wiesand> Hello Mike
[07:04:47] <stephan.wiesand> Since Marc is here, we can start with Linux 3.11.
[07:04:57] <meffie> new solaris 10/11 bots are running and seem happy.
[07:05:14] <Marc Dionne> yeah don't you love those last second changes
[07:05:28] <stephan.wiesand> Marc, are you positive that 10219 is all that's required to support 3.11?
[07:05:37] <stephan.wiesand> Yeah, I do...
[07:05:47] <stephan.wiesand> Mike: Thanks :)
[07:06:07] <Marc Dionne> well it's all that's required to compile - i'm trying to run some basic client tests but having other issues with the machine involved
[07:06:44] <stephan.wiesand> Good enough for pre1, especially since that will take a few more days anyway.
[07:07:22] <stephan.wiesand> And before we know that, we don't have to bother thinking about 1.6.5.1 too.
[07:07:35] <Marc Dionne> once i can confirm that it runs ok, i will post something to the release list.  there shouldn't be a problem since there's no functional changes there
[07:08:14] <Marc Dionne> .. and I did run a client on 3.11 extensively before that change 
[07:09:07] <stephan.wiesand> But even though not too many are here, I'd like to solicit opinions: branch for 1.6.5.1, or try to get 1.6.6pre1 out rather soon and consider that good enough for those running bleeding edge Linux?
[07:10:13] <stephan.wiesand> Any thoughts?
[07:10:36] <deason> I vote the latter, but if we release a .1, I wouldn't be doing much for it :)
[07:10:40] <Marc Dionne> did we do a 1.6.3.1 previously (or whatever the version was) for linux?
[07:10:54] <meffie> well, i assume you want to avoid branches if you can?
[07:11:16] <deason> the last one was 1.6.2.1
[07:11:18] <stephan.wiesand> Marc: We did, and I lost track of the versions too ;-)
[07:11:31] <Marc Dionne> does it have to be a branch, or can it just be a tag
[07:11:48] <stephan.wiesand> Mike: It's the gatekeepers more than me who despise branches.
[07:12:06] <meffie> ok
[07:12:06] <deason> it needs to be a branch at this point, since 1.6.x already has a ton of other stuff on it
[07:12:21] <stephan.wiesand> Marc: Since we have merged dozens of changes at this point, I think it needs to be a branch.
[07:12:29] <Marc Dionne> ah, so you'd do 1.6.5 with just the additional change
[07:12:35] <meffie> ah.
[07:13:04] <stephan.wiesand> We merged the then known Linux 3.11 change first.
[07:14:03] <stephan.wiesand> But then I was stupid and didn't merge a "make 1.6.5.1" on top of that. This is what we could have tagged, hadn't this last minute change be accepted into the kernel. Now, it doesn't matter anymore.
[07:15:22] <stephan.wiesand> It's still feasible, I believe. Just branch at that first 3.11 change after 1.6.5, apply the second 3.11 change + "make 1.6.5.1", tag, release.
[07:15:50] <stephan.wiesand> But frankly I'd rather spend my time on 1.6.6.
[07:15:57] <Marc Dionne> a 1.6.5.1 makes more sense to me, but that may be more work, and I don't know which is better from the end user's perspective
[07:18:08] <stephan.wiesand> From the end user's perspective, 1.6.5.1 is better - if you must run Linux 3.11 now but otherwise prefer things to be as stable as possible.
[07:18:26] <stephan.wiesand> Which is kind of a contradiction in itself IMO.
[07:19:28] <Marc Dionne> btw fedora only recently moved to a 3.10 kernel for the stable release - not sure they'll move to 3.11 quickly
[07:19:45] <stephan.wiesand> Probably within a few weeks.
[07:20:03] <stephan.wiesand> Most likely before the 1.6.6 release.
[07:20:48] <Marc Dionne> well for 3.10 it was more like a few months, but maybe there were issues
[07:21:46] <stephan.wiesand> I'm not saying I'm totally opposed to 1.6.5.1. Just that it will take time away from 1.6.6. And we need the blessing of the gatekeepers for it at this point.
[07:21:52] <meffie> and what about the other distros?
[07:22:36] <meffie> i assume it will be some time until they ship 3.11.
[07:22:44] <stephan.wiesand> It's no issue for RHEL and SLES at least for quite a while - if ever for current major releases.
[07:23:09] <stephan.wiesand> The same for Ubuntu and debian stable.
[07:23:29] <Marc Dionne> ubuntu is planning 13.10 with 3.11, for oct 17
[07:24:10] <meffie> good information.
[07:24:11] <stephan.wiesand> But that's an STS release like Fedora.
[07:24:57] <stephan.wiesand> 1.6.6 before October 17th isn't realistic.
[07:25:04] <Marc Dionne> yes, the next version after thould be an LTS
[07:26:00] <stephan.wiesand> I'll just take the poll: If it were your decision: 1.6.51 yes or no?
[07:27:14] <deason> no (but I'd take 1.6.5.1 over 1.6.51 ;)
[07:27:27] <deason> a poll on release-team or -devel may make more sense, though
[07:27:53] <stephan.wiesand> Obviously, this is not going to be the final verdict.
[07:28:24] <meffie> well, i'd say if patches are available, then users on bleeding egde releases would use those.
[07:28:24] <deason> also, debian can and will pull patches for kernel support, if/when they get 3.11
[07:28:25] <stephan.wiesand> I'm still interested in *your* opinion. And yes, it's about 1.6.5.1 :-)
[07:29:07] <meffie> a branch can be made, but we dont have to make release bins for bleeding edge users. they are free to do so?
[07:29:19] <deason> it's only an issue for the places that don't generate their own packages and are thus able to apply their own patches
[07:29:22] <shadow@gmail.com/barnowlF905C30D> 1.6.5.1 seems fine, imo
[07:29:48] <stephan.wiesand> Sigh ;-)
[07:31:32] <stephan.wiesand> Mike: Binaries make sense for current Fedora only. Stephen builds those, and I figure he'd do it.
[07:32:49] <meffie> ok
[07:33:50] <meffie> so, you mean he needs a tag on openafs.org to do that?
[07:34:01] <stephan.wiesand> Needs more discussion on release-team. Though after Derrick's input, I guess we'll have a 1.6.5.1.
[07:34:25] <stephan.wiesand> Mike: we can do it quick & dirty. I doubt we'd want to.
[07:35:24] <meffie> sorry, i dont mean to imply short cuts, i'm just trying to understand why it's an issue for us.
[07:35:27] <shadow@gmail.com/barnowlF905C30D> thing is, i don't think a .1 is that much work, period. you make a
source tarball and a srpm, the srpm hits the build farm, and debian
does what it does
[07:35:55] --- kaduk has become available
[07:37:37] <stephan.wiesand> Well, we need a branch, and a tag, and a volume on grand.central.org <http://grand.central.org>, and it populated, and release notes, and a release page, and an announcement.
[07:37:57] <kaduk> Ugh, it feels like pidgin is even more reluctant to join a federated MUC than barnowl was.
[07:38:11] <deason> yeah, the worst thing that happens is that it's a waste of time; but it also doesn't seem like a lot of time to me
[07:38:18] <stephan.wiesand> No big deal, but certainly not negligible.
[07:39:43] <shadow@gmail.com/barnowlF905C30D> branch: simon. tag: me. volume: several of us. populated: whoever
makes the volume. release notes: 1.6.5 plus one line. release page: we
have a script. announcement: "... wish to announce the release of
OpenAFS 1.6.5.1. This release contains support for Linux 3.11. It is
otherwise unchanged from OpenAFS 1.6.5. Sites not using Linux 3.11
should continue using OpenAFS 1.6.5"
[07:39:45] <stephan.wiesand> It also still requires manual updates of the volume content (or there's indeed no point in providing binaries at all).
[07:40:56] <stephan.wiesand> Okok, will ask Simon for the branch.
[07:41:02] <stephan.wiesand> Next topic?
[07:41:46] <stephan.wiesand> RT #131716: any news?
[07:42:56] <stephan.wiesand> Should it be considered critical to fix in 1.6.6?
[07:43:04] <meffie> i poked that. chaskiel updated.
[07:43:21] <stephan.wiesand> It's configure-time, right?
[07:43:41] <kaduk> partially.
[07:44:04] <stephan.wiesand> Sigh. This means I'm still not even understanding the problem.
[07:44:41] <kaduk> There are multiple problems, I think.
[07:45:42] <kaduk> One is that configure is not being sufficiently robust when verifying that a com_err routine is available.
[07:46:15] <kaduk> Another is that aklog.c includes a header with insufficient conditionals (which would reflect the more robust configure checks).
[07:48:01] <meffie> so, it's a build break on some platforms? (netbsd 6?)
[07:48:16] <stephan.wiesand> Would pulling up 7554 be a start?
[07:48:38] <kaduk> If I'm reading it right, it would be a build break somewhere.  But I haven't had any caffeine yet this morning.
[07:48:52] <deason> it's not clear; I just asked more directly
[07:49:30] <meffie> heh. thank you.
[07:49:55] <stephan.wiesand> Is it a regression?
[07:50:06] <kaduk> It's not immediately obvious to me that a 7554 pullup is the right thing.  It might be.
[07:50:13] <deason> probably not a regression
[07:51:14] <deason> no, 7554 isn't what he's talking about, it's just something else that's in the same area of code
[07:51:33] <meffie> separate from this ticket, fixing the aklog error messages would be a very good thing imho.
[07:51:46] <deason> yes
[07:52:05] <deason> but we shouldn't waste time in here just guessing what he means in 131716
[07:52:35] <meffie> yep
[07:52:56] <stephan.wiesand> Right. Still, will pulling up 7554 fix the error messages?
[07:53:21] <stephan.wiesand> If so, any volunteer? 
[07:53:55] <meffie> dont know. i call look. 
[07:54:11] <meffie> *can
[07:54:18] <stephan.wiesand> Thanks.
[07:54:23] <deason> I'm not sure if it's just that; I assumed there were various fixes for that for various platforms
[07:54:53] <deason> but "fixing aklog error strings" would be nice if mike can look
[07:55:17] <stephan.wiesand> Fine. Next one: 10165 & 10167
[07:55:45] <stephan.wiesand> Sorry the minutes were late again. No surprise thay haven't had more review.
[07:56:27] <stephan.wiesand> No further news on those, I guess.
[07:57:09] <stephan.wiesand> Next one: 10219. Marc, could you pull it up as soon as it's tested and accepted on master?
[07:57:29] <Marc Dionne> sure
[07:57:36] <stephan.wiesand> Thanks.
[07:58:09] <stephan.wiesand> On to Sabah's latest problem:  10213/14. Crucial for 1.6.6?
[07:58:50] <deason> imo no, but 10213 fixes a regression, as mentioned
[08:00:20] <stephan.wiesand> Ok, noted (again). 10214 seems the simpler of those?
[08:00:39] <deason> it also allegedly doesn't build on some of the windows slaves... but that failure looks maybe spurious
[08:00:54] <stephan.wiesand> 10213?
[08:01:14] <deason> well both of the mfailed, but they both look like reasons unrelated to the code
[08:01:17] <deason> I'll look at it
[08:01:44] <stephan.wiesand> But I take it 1.6.6 shouldn't block on those.
[08:02:02] <deason> nah
[08:02:28] <stephan.wiesand> How about the Linux keyring issue Christof brought up? 10179/10194 ?
[08:04:37] <stephan.wiesand> My feeling is we should try to have those in 1.6.6 if feasible.
[08:05:10] <meffie> yes, i think i agree
[08:05:22] <Marc Dionne> probably;  should only affect suse though
[08:06:01] <stephan.wiesand> The missing diagnostic could affect others too?
[08:07:22] <stephan.wiesand> I recall keyring quota issues on RHEL5 in the past.
[08:07:27] <Marc Dionne> maybe, but not sure we've seen errors there on other platforms; the other problem triggered the error
[08:08:05] <kaduk> We had keyring errors when pam(?) was pulling keyrings out of root's quota.
[08:08:28] <stephan.wiesand> Anyway, probably not a blocker but would be good to have in 1.6.6. Even if it's just for SLES (we're doing a release for Fedora...).
[08:09:19] <Marc Dionne> this is a different call where i think we haven't seen errors before.  those changes don't look very risky to include
[08:09:43] <kaduk> Yup, they're small and contained.
[08:09:55] <stephan.wiesand> Ok, thanks. Next one: the ihandle changes: 10175..8
[08:11:09] <kaduk> The commit messages sound reasonable enough..
[08:11:13] <deason> those aren't critical
[08:11:51] <stephan.wiesand> Should they go in? If yes, why not now?
[08:12:29] <deason> I think they should go in
[08:13:00] <stephan.wiesand> Obviously ;-)
[08:13:02] <deason> I'm not saying "not now", just that I'll work on getting reviews for them; I don't think they need specific attention here or anything
[08:13:14] <stephan.wiesand> Ok
[08:14:09] <stephan.wiesand> I'm not sure it makes sense to go through the others I've listed one by one today.
[08:14:27] <stephan.wiesand> Just take the agenda as you "1 week's notice" ;-)
[08:14:40] <kaduk> If even that.
[08:14:49] <stephan.wiesand> But, Derrick, if you're still active...
[08:14:56] <kaduk> You might just add a couple review requests to them now.
[08:15:13] <kaduk> Hmm, or are those ones that need to have a new pullup submitted.
[08:15:21] <stephan.wiesand> I did for some a while ago, without great response.
[08:15:58] <stephan.wiesand> No, most will merge after a trivial rebase, 2 or 3 after an almost trivial one.
[08:16:28] <kaduk> Oh, I just meant that those numbers looked too low to be 1.6 submissions, so they must be the original master submissions.
[08:16:44] <stephan.wiesand> No, they're just from spring.
[08:17:20] <stephan.wiesand> The ones not having pullups yet were marked so in yesterday's invitation.
[08:17:27] <kaduk> Okay.
[08:17:49] <stephan.wiesand> But even though Derrick hasn't responded...
[08:18:14] <stephan.wiesand> How about changes like 10096?
[08:18:41] <kaduk> 10096 seems worth taking.
[08:19:00] <deason> it fixes something, and there's a clear reason in the commit message why it's not a pullup from master
[08:19:31] <stephan.wiesand> That's what I think. But it doesn't come from master. I really think a gatekeeper should bless it before I merge it.
[08:20:28] <kaduk> I don't feel as strongly as you do that that is the case.
[08:21:30] <deason> but it shouldn't be hard to get that :)
[08:22:32] <stephan.wiesand> Well, I invited the two gatekeepers I can to review it, days ago, no response. The third one I can't invite because "gerrit hates him" (quoting Simon).
[08:24:08] <stephan.wiesand> Ben: Thanks for your input.
[08:24:11] <kaduk> Hmm, I'm still waiting on rxgk review from Simon...
[08:25:21] <stephan.wiesand> Simon just said that. It's Jeffrey gerrit is telling me "is not a registered user" whenever I try to imvite him (using gerrit's autocompletion).
[08:26:26] <deason> I just added him using jaltman@openafs.org
[08:26:40] <deason> which for some reason does work, even though on the page it reports him as jaltman@yfs
[08:26:50] <deason> so, there you go :)
[08:27:07] <stephan.wiesand> Thanks :)
[08:28:15] <stephan.wiesand> Regarding 10148   bozo: cap retry delay: is the final version on 1_6_X now?

[08:28:50] <meffie> well, hoping the patch for master would go in. 
[08:29:00] <deason> well, mike submitted it to 1.6.x iirc, but it needs to be on master before the commit message can be fixed
[08:29:27] <shadow@gmail.com/barnowlF905C30D> i guess my messages weren't sending again. sigh
[08:29:34] <Jeffrey Altman> 10096 is approved
[08:29:47] <meffie> i submitted both, actually.
[08:30:06] <stephan.wiesand> Derrick, Jeff, thanks for 10096.
[08:30:50] <stephan.wiesand> But what's your general stance on changes like that one? Ok to merge without  a +1 from a gatekeeper?
[08:31:35] <shadow@gmail.com/barnowlF905C30D> my take is "unless some controversy arose since something hit master,
if you think it's good in 1.6 take it"
[08:31:52] <stephan.wiesand> Well this one didn't hit master.
[08:32:19] <shadow@gmail.com/barnowlF905C30D> yeah, but this is a weird case. this one is still noncontroversial
[08:32:27] <Jeffrey Altman> I think that if it never received an approval you should strive to get one.  However, that being said.  You are the release manager for 1.6 and should feel free to submit things that you are comfortable with.
[08:32:38] <deason> well he's specifically asking about the "weird cases" :)
[08:33:40] <stephan.wiesand> Ok, taking all this as "no hard and fast rules". Will still fell better when merging 10096 now. Thanks.
[08:33:44] <Jeffrey Altman> If you are uncomfortable, you should block on gatekeeper review.  
[08:34:37] <stephan.wiesand> When I really feel uncomfortable, I'll block even with a +1 from a gatekeeper ;-)
[08:34:57] <shadow@gmail.com/barnowlF905C30D> that's fine
[08:35:19] <Jeffrey Altman> as you should
[08:35:56] <stephan.wiesand> Ok, Thanks.
[08:36:18] <stephan.wiesand> Sorting out Linux 3.11 may take a few days.
[08:36:42] <stephan.wiesand> So we needn't discuss 1.6.6 / 1.6.5.1 schedules now. 
[08:36:52] <stephan.wiesand> Anything else to discuss today?
[08:38:29] <stephan.wiesand> If not, thanks a lot everyone. I hope I'll get the minutes out more timely this time. Shame on me.
[08:39:44] <kaduk> Thanks for writing them up!
[08:39:56] <meffie> thank you stephan.wiesand
[08:41:23] <stephan.wiesand> Bye.
[08:42:05] --- stephan.wiesand has left
[08:42:37] --- kaduk has left
[08:53:19] --- Marc Dionne has left
[09:27:40] --- meffie has left
[10:47:59] --- meffie has become available
[10:58:15] --- meffie has left
[11:56:46] --- meffie has become available
[11:57:49] --- meffie has left
[11:57:50] --- meffie has become available
[11:58:19] --- meffie has left
[11:59:14] --- meffie has become available
[12:00:42] --- meffie has left
[12:00:43] --- meffie has become available
[12:02:25] --- meffie has left
[12:03:04] --- meffie has become available
[13:02:36] --- Jeffrey Altman has left: Disconnected
[13:10:45] --- Jeffrey Altman has become available
[16:02:28] --- deason has left
[18:06:27] --- meffie has left