- Wednesday, August 13, 2014

release-team@conference.openafs.org

Wednesday, August 13, 2014< ^ >

Room Configuration

Room Occupants

GMT+0
[11:56:14] meffie joins the room
[12:00:57] wiesand joins the room
[12:58:03] meffie leaves the room
[13:57:02] meffie joins the room
[14:01:20] <wiesand> Agenda updates: 1) The FBSD changes are merged  2) stack-reduction needs another fix: 11381 3) 11380 should be backported to 1.6
[14:01:57] deason joins the room
[14:02:06] <wiesand> Hello
[14:02:13] <deason> hi
[14:02:43] <meffie> hi
[14:02:43] kaduk joins the room
[14:03:11] <kaduk> hello.
[14:03:49] <wiesand> Any gatekeepers around today?
[14:04:01] <kaduk> Jeff is merging things.
[14:05:35] <wiesand> Let's postpone Linux. My first item would then be 11242. Is this ok to merge?
[14:06:15] <kaduk> tvolser hasn't really caused us trouble on master, so I'd say it's probably okay to merge.
[14:06:50] <wiesand> Mike, the last patchset puts back one line your version removed. Are you ok with this?
[14:07:34] <meffie> sorry? looking
[14:09:25] <meffie> sorry, i dont see the line you mention.
[14:10:06] <kaduk> ptserver/Makefile.in
[14:10:20] <kaduk> ptuser.o depends on ${LINCLS}
[14:11:12] <deason> it's a comment in PS4
[14:11:12] <meffie> ah.
[14:11:13] <wiesand> If we had a gatekeeper here, we could beg for 11362 and 11370...
[14:13:19] <wiesand> So, any objections to 11242?
[14:14:13] <meffie> no, that seems right.
[14:14:46] <deason> 11242: one sec, please
[14:16:11] <deason> in the master version, there's a section that fixes a makefile for some dumpscan files
[14:16:25] <deason> and the 1.6 one does not; but dumpscan isn't built by default
[14:16:55] <deason> so, do we care?
[14:18:31] <kaduk> It appears to be in src/tests/ on 1.6?
[14:19:21] <kaduk> I think it is probably acceptable to require a serial build in tests/
[14:20:07] <deason> yes
[14:21:06] <wiesand> It's not nice. But I don't want to delay pre1 for this, nor would I like to defer the change to 1.6.11.
[14:21:50] <wiesand> So if you don't want me to press the submit button, speak up now.
[14:21:54] <deason> so put it in the meeting notes to try to fix it before the release, and bug us about it every week :)
[14:22:15] <wiesand> Ok.
[14:23:21] <wiesand> Merging takes a while these days.
[14:23:49] <wiesand> Any objections to 11367?
[14:23:51] <kaduk> Even commenting does.
I suppose I could check if the machine looks loaded...
[14:24:09] <kaduk> I anti-object to 11367
[14:25:09] <wiesand> Merging...
[14:25:38] <meffie> heh
[14:26:25] <wiesand> Done.
[14:26:56] <wiesand> Next item: http://gerrit.openafs.org/#q,status:open+project:openafs+branch:openafs-stable-1_6_x+topic:stack-reduction,n,z
[14:27:03] <kaduk> The load on openafs.mit.edu seems pretty low, and java isn't even using an absurd fraction of memory.  Not sure why things feel sluggish.
[14:27:45] <wiesand> Thanks for checking.
[14:27:49] <kaduk> I think stack-reduction is in pretty good shape; there was just the one spot where Andrew had tidied the code up on master that didn't get merged.
[14:28:27] <kaduk> I guess I didn't comment on 11339 for some reason; I guess I can look at that now.
[14:28:30] <wiesand> Yes, 11381 was indeed missing.
[14:28:41] <deason> I would've preferred 11381 go in ahead of 11161, but I guess it's not that important
[14:29:04] <deason> but if it goes in after, it could maybe use a 1.6-specific note that it also fixes the vrequest leak
[14:29:26] <wiesand> 11161?
[14:29:58] <deason> er, 11166
[14:30:30] <meffie> ouch. com.google.gwtorm.client.OrmException: Cannot open database connection
[14:30:43] <wiesand> If we merge 11381, we have to rebase the stack again.
[14:31:18] <wiesand> Ah, DB backend.. that could explain why things feel slow...
[14:31:31] <meffie> ah, gerrit is back
[14:33:13] <kaduk> I didn't think there was anything else that touched VNOPS after 11166.  Did I miss something?
[14:33:52] <wiesand> 11364...
[14:34:53] <kaduk> But that's just afs_vnop_lookup.c, and 11381 is just afs_vnop_flock.c; they should be orthogonal
[14:35:53] <deason> I assumed 11381 would still cause a conflict in 11166 itself at least, since it touches around the same part itself
[14:35:57] <wiesand> Ok, it's only half the stack we'd have to rebase.
[14:36:30] <kaduk> 11381 and 11166 would conflict, yes.  I have the current version of 11381 as on top of 11166, so if 11166 is merged first, I think things are okay.
[14:41:40] <wiesand> Andrew, you want a note in the commit message?
[14:42:47] <wiesand> Defer the whole thing to 1.6.11?
[14:45:29] <deason> a note in the commit message would be nice
[14:45:30] <wiesand> But then it's entangled with 11358.
[14:46:21] <kaduk> I don't see a conflict between 11358 and 11381.
[14:47:59] <meffie> would it be better to rebase the stack reduction patches on top of 11358?
[14:48:19] <meffie> before you try to merge to the openafs-stable-1_6_x branch?
[14:48:47] <kaduk> It would be moderately more aesthetically clean, but take longer for buildbot to chew through.
[14:50:19] <wiesand> Right.
[14:50:54] <deason> just put a note in the commit message and it's fine; that sounds easiest
[14:50:57] <kaduk> I'm happy to push a new 11381 with a comment if that's what we want.
[14:52:43] <wiesand> Ben, please do.
[14:53:06] <kaduk> I already did ;)
[14:54:06] <wiesand> And then I'd like to merge the whole thing in the order the dependencies indicate.
[14:54:52] <wiesand> Although that's a tree now...
[14:55:07] <kaduk> Sorry.
[14:55:25] <kaduk> "Just think of it as a partial order; you can apply whatever full order you like which is consistent with the existing partial order"
[14:56:13] <wiesand> Hopefully. Let's see what gerrit thinks.
[14:57:15] <wiesand> While we wait for buildbot and +1s on 11381: Can we look at 11361?
[15:00:56] <wiesand> And 11358: any objections?
[15:04:02] <kaduk> I do not see anything wrong with 11361; however, I also have no familiarity with the afs_linux_lock() routine, so that may not be saying much.
[15:05:07] <wiesand> Marc +1ed the change on master.
[15:05:35] <kaduk> Yeah, I mean, it's probably fine.  "Just don't blame me if it's not" :)
[15:08:53] <wiesand> It's a fix for a reported problem, master has +1s from Daria and Marc, 1.6 from Andrew, Chas, and Mike, and you say it's probably fine. I'll merge it after its dependencies.
[15:11:58] <wiesand> Jeffrey just -1'ed 11362
[15:12:54] <kaduk> buildbot is happy with the "revised" 11381
[15:13:58] <wiesand> About to merge stack-reduction + that... stop me
[15:15:26] <wiesand> Gerrit stopped me.
[15:15:48] <meffie> oh, i'm happy to use bsd license for 11362, i was just trying to be conservative
[15:16:19] <kaduk> shucks.
[15:17:35] <kaduk> where?
[15:18:24] <wiesand> It sever times errored out with either "internal server error" or the DB error message you saw too.
[15:18:39] <kaduk> I can bounce gerrit if you want to wait a few minutes for it to come back...
[15:18:55] <wiesand> Does that include the DB backend?
[15:19:17] <kaduk> I think so; I didn't notice any standalone db processes running.
[15:19:44] <wiesand> Let's try.
[15:20:46] <kaduk> Okay, things should be (slowly) starting back up now.
[15:20:53] <kaduk> (I have no more feedback on the console)
[15:20:54] <wiesand> Thanks.
[15:21:51] <kaduk> I have a web interface.
[15:22:23] <wiesand> trying to merge 11166...
[15:23:28] <wiesand> Much better.
[15:24:07] <kaduk> hooray
[15:25:18] <wiesand> merged 11381.
[15:29:26] <wiesand> stack-reduction merged, continuing with the linux fixes
[15:31:38] <wiesand> done.
[15:32:14] <wiesand> on to volscan...
[15:32:50] <wiesand> Do we think we'll get this in today?
[15:33:36] <meffie> i built and smoke tested the "volscan" stack yesterday, seems to work fine here.
[15:33:39] <meffie> btw
[15:33:46] <wiesand> So it does here.
[15:34:26] <meffie> it's a shame 1.6 does not have simon's cleanup for cmd though for at least formating usage messages :)
[15:35:04] <wiesand> That was declined ;-)
[15:35:30] <meffie> yes, understood. :)
[15:35:42] <kaduk> "It'll be in 1.8"
[15:36:20] <wiesand> Merging this stack today will take too long. We still need pullups of 11370 and 11362. 11370 was merged, so no problem. 11362 seems on its way, but who knows.
[15:37:13] <wiesand> Since we're really close, I propose we wait for it until tomorrow.
[15:37:34] <wiesand> That is, if there are no objections to merging the stack.
[15:37:43] <wiesand> Some changes have very few +1 yet.
[15:38:49] <wiesand> Chances are we'll have to wait for the tag for up to a couple of days anyway.
[15:40:05] <wiesand> Has anyone looked into the draft release notes?
[15:42:24] <wiesand> Another nit with 11362.
[15:42:32] <kaduk> I looked at the draft release notes just now.
[15:44:46] <wiesand> So, my plan is to produce and upload inofficial tarballs tomorrow. With volscan, if possible (blocks on 11362). Otherwise, have pre1 without it. I think this could even go into pre2 because it touches upon very dew places.
[15:45:30] <wiesand> And are they very bad?
[15:46:56] <deason> draft notes are 11343
[15:47:23] <kaduk> Skimming the volscan series, it does appear to be entirely standalone, as everyone has been saying.
[15:47:39] <kaduk> I didn't see any problems in the draft release notes.
[15:47:54] <wiesand> Thanks.
[15:49:09] <deason> I don't think it's ever been consistent, but just IMO, the notes read better when they are in present tense
[15:49:16] <deason> like "fix bug X" instead of "fixed bug X"
[15:49:39] <deason> but that's maybe just a preference of mine :)
[15:50:11] <wiesand> Well, it's your native language, so I should listen to you.
[15:50:54] <wiesand> On the other hand, I'm distinguishing deliberately: "Fixed this bug" vs. "don't print log messages twice".
[15:51:53] <wiesand> Buildbot likes 11362. Jeffrey doesn't...
[15:53:03] <deason> it's not a "grammar correctness" thing; it's a preference of how the notes just look
[15:53:39] <deason> I could give an example in german, too, if I knew how to say anything in past-tense in german
[15:54:10] <wiesand> [release notes] I think it avoids some ambiguities to use present for saying what the software does and past for developers' actions.
[15:55:01] <wiesand> "Fehler beseitigt" vs "Fehlermeldungen nur einmal ausgeben"
[15:57:52] <wiesand> But german release notes are pretty uncommon :)
[15:58:47] <wiesand> Mike, any chance we get a 11362 Jeffrey may approve? ;-)
[15:59:32] <wiesand> 11370 pull-up is 11387
[15:59:33] <meffie> just pushed...
[16:01:04] <wiesand> (really sorry for bringing up the BSD licensing ;-)
[16:03:19] <meffie> it is an appropriate question. i was just trying to be conservative and not inadvertently relicense IPL code.
[16:04:37] <deason> if you (or sna) has the copyright, the license is whatever; changing the copyright owner has already made that leap
[16:05:13] <deason> and while it may seem trivial, it's better to get it out of the way now than 10 years from now
[16:05:22] <meffie> yes, agreed.
[16:05:50] <kaduk> Yeah.  Over in another window, we are talking about the license on tkt_DeriveDesKey, which was not really handled when it was committed.
[16:06:05] <meffie> ug
[16:09:14] <meffie> (lunch time in this time zone.)
[16:09:28] <wiesand> Dinner time here...
[16:09:54] <wiesand> Jeffrey gave us 11362 :) Thanks!
[16:09:59] <meffie> so we all get to eat? cool. have a good evening.
[16:10:35] <wiesand> I heard no ibjections to the "tarballs tomorrow" plan. So I'll pursue that.
[16:10:58] <wiesand> Thanks a lot for participating!
[16:11:19] meffie leaves the room
[16:11:51] <deason> I can pullup 11362 in a bit, but it's a little tricky because of the existing changes
[16:12:29] <deason> since it touches volscan-main.c and the man page, it needs to go after everything in the volscan stack, but a few late changes are not 'up to date'
[16:12:37] <deason> I guess I can just rebase the later ones so they're all consistent
[16:12:48] <deason> buildbot doesn't seem too behind at the moment
[16:12:52] <wiesand> If you could do that...
[16:13:02] <wiesand> I think it's just two changes anyway.
[16:13:06] <wiesand> Plus this one.
[16:15:17] <wiesand> I'll be offline for ~ an hour. Bye.
[16:15:41] wiesand leaves the room
[17:51:37] kaduk leaves the room
[20:45:17] kaduk joins the room
[22:18:43] kaduk leaves the room
[23:27:47] deason leaves the room